Author | Topic: Bitmap 14byte Header PDR 6009 | |
---|---|---|
AUGE_OHR | Bitmap 14byte Header PDR 6009 on Sat, 06 Feb 2010 23:38:42 +0100 hi, http://www.alaska-software.com/scripts/waa001.dll?WAA_PACKAGE=PUBLICDTS&WAA_FORM=DISPLAYPDR&PDRID=6009 i can see that PDR 6009 ist "close", but i can not find a Hotfix No. ? can someone tell me which Hotfix it is ? what does "close" meen for us ? we do have store Bitmap in Xbase++ Memo (Type V) with :setbuffer() where we did not have 1st 14byte while other Programm need this 14byte, they can not read Xbase++ Memo (Type V) how do we "convert" all Bitmap from old Memo to new "fixed" Memo ? greeting by OHR Jimmy | |
Edgar Borger | Re: Bitmap 14byte Header PDR 6009 on Mon, 08 Feb 2010 09:30:01 -0200 Hi Jimmy, I think what they mean, is that that's your problem, not theirs ..... you build the 14 byte header !!!!! It basically contains the size of the file, width, and height of the image..... Regards, Edgar AUGE_OHR escreveu: > hi, > > http://www.alaska-software.com/scripts/waa001.dll?WAA_PACKAGE=PUBLICDTS&WAA_FORM=DISPLAYPDR&PDRID=6009 > > i can see that PDR 6009 ist "close", but i can not find a Hotfix No. ? > can someone tell me which Hotfix it is ? > > what does "close" meen for us ? > we do have store Bitmap in Xbase++ Memo (Type V) with :setbuffer() where we > did not have 1st 14byte > while other Programm need this 14byte, they can not read Xbase++ Memo (Type > V) > > how do we "convert" all Bitmap from old Memo to new "fixed" Memo ? > > greeting by OHR > Jimmy > > Edgar Borger Softsupply Informatica Ltda. Rua Alagoas, 48 Sao Paulo, SP 01242-000 Tel : (5511) 3159-1997 Fax : (5511) 3255-5224 | |
Jack Duijf | Re: Bitmap 14byte Header PDR 6009 on Tue, 09 Feb 2010 23:27:16 +0100 Hello Auge, How did you put the bitmap in the Xbase++ memo file in the first place? Did you use Fread()?? Is so, then the content of the memo should be identical a the full content of the bitmap file. It would be helpfull if you could post a simple test programm that shows the problem. (including otiginal bitmap file) Regards, Jack Duijf Op 6-2-2010 23:38, AUGE_OHR schreef: > hi, > > http://www.alaska-software.com/scripts/waa001.dll?WAA_PACKAGE=PUBLICDTS&WAA_FORM=DISPLAYPDR&PDRID=6009 > > i can see that PDR 6009 ist "close", but i can not find a Hotfix No. ? > can someone tell me which Hotfix it is ? > > what does "close" meen for us ? > we do have store Bitmap in Xbase++ Memo (Type V) with :setbuffer() where we > did not have 1st 14byte > while other Programm need this 14byte, they can not read Xbase++ Memo (Type > V) > > how do we "convert" all Bitmap from old Memo to new "fixed" Memo ? > > greeting by OHR > Jimmy > > | |
AUGE_OHR | Re: Bitmap 14byte Header PDR 6009 on Wed, 10 Feb 2010 05:24:54 +0100 hi, > How did you put the bitmap in the Xbase++ memo file in the first place? the "normal" Xbase++ Way with :setbuffer() > Did you use Fread()?? i know this Way, but my Bitmap are not on Harddisk, so not Fxxxx() > It would be helpfull if you could post a simple test programm that shows > the problem. (including otiginal bitmap file) as i say it is the "normal" Xbase++ Way to handle XbpBitmap() i do a "Snapshot" from running Video (Overlay) with WMP activeX *** Code *** Screen2Bitmap( aoChild[CH_WMP],; {0,0,aSize[1],aSize[2]},; STRZERO(MARKPLAY->(RECNO()),6),; 2,; aDLGOWNER,; ALIAS() ) FUNCTION Screen2Bitmap(oSourceArea,aRect ,cArtnr,InOut,aDLGOWNER,cALIAS) oSourceArea Xbase++ Object aRect Koordinate LOCAL oTargetPS := XbpPresSpace():new():create() LOCAL oBitmap := XbpBitmap():new():create() LOCAL oThumb := XbpBitmap():new():create() LOCAL oPS := NIL LOCAL nSizeX := aRect[3] - aRect[1] LOCAL nSizeY := aRect[4] - aRect[2] LOCAL cBildnr := TRIM(cArtnr) LOCAL cSavePic DEFAULT InOut TO 0 0 = Fullsize oPS := oSourceArea:lockPS() IF InOut = 0 fullsize oBitmap:presSpace(oTargetPS) oBitmap:make(nSizeX,nSizeY) GraBitBlt(oTargetPS,oPS,{0,0,nSizeX,nSizeY},aRect) ELSE oThumb:presSpace(oTargetPS) Size from DBF oThumb:make(SP_BMPxSize(),SP_BMPySize()) Orientation Portrait or Landscape IF nSizeX <= SP_BMPxSize() GraBitBlt(oTargetPS,oPS,{0,0,SP_BMPxSize(),SP_BMPySize()},; {0,0,SP_BMPxSize(),SP_BMPySize()},; GRA_BLT_ROP_SRCPAINT,GRA_BLT_BBO_IGNORE) ELSE GraBitBlt(oTargetPS,oPS,{0,0,SP_BMPxSize(),SP_BMPySize()},; {0,0,nSizeX - 1,nSizeY - 1},; GRA_BLT_ROP_SRCPAINT,GRA_BLT_BBO_IGNORE) ENDIF ENDIF oSourceArea:unLockPS(oPS) Sleep(0) oTargetPS:destroy() oTargetPS := NIL oPS := NIL save to Memo Type V using :Setbuffer() IF &(cALIAS)->(DBRLOCK()) DO CASE CASE InOut = 0 CASE InOut = 1 &(cALIAS)->BILDIN := oThumb:SetBuffer(,XBPBMP_FORMAT_WIN3X) cBildnr := "Y"+cBildnr+"A" CASE InOut = 2 &(cALIAS)->BILDOUT := oThumb:SetBuffer(,XBPBMP_FORMAT_WIN3X) cBildnr := "Y"+cBildnr+"B" ENDCASE &(cALIAS)->(DBUNLOCK()) COMMIT ENDIF save as external JPG ... IF .NOT. EMPTY(SP_BMPPATH()) cSavePic := SP_BMPPATH()+cBildnr+".JPG" IF FILE(cSavePic) FERASE(cSavePic) ENDIF oThumb:SaveFile(cSavePic,XBPBMP_FORMAT_JPG,50) ENDIF oThumb:Destroy() oThumb := NIL destroy it oBitmap:Destroy() oBitmap := NIL RETURN NIL ***eof *** i enhance it to :SaveFile() "external", but i like to use Xbase++ Memo Type "V". i hope "fix" of PDR 6009 will include 14byte Header of Bitmap when using:Setbuffer() and Memo. greetings by OHR Jimmy | |
Edgar Borger | Re: Bitmap 14byte Header PDR 6009 on Wed, 10 Feb 2010 16:56:46 -0200 Hi Jimmy, why don't you change the format in :setbuffer() ? if you use JPG or PNG format your memo will be complete and also much smaller, saving disk space. (not a big issue today, but anyhow...) the other options as I said before is build it yourself and save it to a second memo field (or maybe concatenate to the same one) the header is : "BM" + length of file (including header - 4 bytes) + zeros (4 bytes) hex 36 (or dec 54) (4 bytes) sample (in HEX) 42 4D C2 0A 00 00 00 00 00 00 36 00 00 00 for a bmp that has a size of 2754 bytes (C2 0A) Regards, Edgar Em 10/2/2010 02:24, AUGE_OHR escreveu: > hi, > >> How did you put the bitmap in the Xbase++ memo file in the first place? > > the "normal" Xbase++ Way with :setbuffer() > >> Did you use Fread()?? > > i know this Way, but my Bitmap are not on Harddisk, so not Fxxxx() > >> It would be helpfull if you could post a simple test programm that shows >> the problem. (including otiginal bitmap file) > > as i say it is the "normal" Xbase++ Way to handle XbpBitmap() > i do a "Snapshot" from running Video (Overlay) with WMP activeX > > *** Code *** > Screen2Bitmap( aoChild[CH_WMP],; > {0,0,aSize[1],aSize[2]},; > STRZERO(MARKPLAY->(RECNO()),6),; > 2,; > aDLGOWNER,; > ALIAS() ) > > FUNCTION Screen2Bitmap(oSourceArea,aRect ,cArtnr,InOut,aDLGOWNER,cALIAS) > > oSourceArea Xbase++ Object > aRect Koordinate > > LOCAL oTargetPS := XbpPresSpace():new():create() > LOCAL oBitmap := XbpBitmap():new():create() > LOCAL oThumb := XbpBitmap():new():create() > LOCAL oPS := NIL > LOCAL nSizeX := aRect[3] - aRect[1] > LOCAL nSizeY := aRect[4] - aRect[2] > LOCAL cBildnr := TRIM(cArtnr) > LOCAL cSavePic > > DEFAULT InOut TO 0 0 = Fullsize > > oPS := oSourceArea:lockPS() > > IF InOut = 0 fullsize > oBitmap:presSpace(oTargetPS) > oBitmap:make(nSizeX,nSizeY) > GraBitBlt(oTargetPS,oPS,{0,0,nSizeX,nSizeY},aRect) > > ELSE > oThumb:presSpace(oTargetPS) > > Size from DBF > > oThumb:make(SP_BMPxSize(),SP_BMPySize()) > > Orientation Portrait or Landscape > > IF nSizeX<= SP_BMPxSize() > GraBitBlt(oTargetPS,oPS,{0,0,SP_BMPxSize(),SP_BMPySize()},; > {0,0,SP_BMPxSize(),SP_BMPySize()},; > GRA_BLT_ROP_SRCPAINT,GRA_BLT_BBO_IGNORE) > ELSE > GraBitBlt(oTargetPS,oPS,{0,0,SP_BMPxSize(),SP_BMPySize()},; > {0,0,nSizeX - 1,nSizeY - 1},; > GRA_BLT_ROP_SRCPAINT,GRA_BLT_BBO_IGNORE) > ENDIF > ENDIF > > oSourceArea:unLockPS(oPS) > Sleep(0) > oTargetPS:destroy() > oTargetPS := NIL > oPS := NIL > > save to Memo Type V using :Setbuffer() > > IF&(cALIAS)->(DBRLOCK()) > DO CASE > CASE InOut = 0 > CASE InOut = 1 > &(cALIAS)->BILDIN := oThumb:SetBuffer(,XBPBMP_FORMAT_WIN3X) > cBildnr := "Y"+cBildnr+"A" > > CASE InOut = 2 > &(cALIAS)->BILDOUT := oThumb:SetBuffer(,XBPBMP_FORMAT_WIN3X) > cBildnr := "Y"+cBildnr+"B" > > ENDCASE > &(cALIAS)->(DBUNLOCK()) > COMMIT > ENDIF > > save as external JPG ... > > IF .NOT. EMPTY(SP_BMPPATH()) > cSavePic := SP_BMPPATH()+cBildnr+".JPG" > IF FILE(cSavePic) > FERASE(cSavePic) > ENDIF > oThumb:SaveFile(cSavePic,XBPBMP_FORMAT_JPG,50) > ENDIF > > oThumb:Destroy() > oThumb := NIL > > destroy it > oBitmap:Destroy() > oBitmap := NIL > > RETURN NIL > > ***eof *** > > i enhance it to :SaveFile() "external", but i like to use Xbase++ Memo Type > "V". > i hope "fix" of PDR 6009 will include 14byte Header of Bitmap when > using:Setbuffer() and Memo. > > greetings by OHR > Jimmy > > | |
AUGE_OHR | Re: Bitmap 14byte Header PDR 6009 on Sat, 13 Feb 2010 04:02:09 +0100 hi, > why don't you change the format in :setbuffer() ? if you use JPG or PNG > format your memo will be complete and also much smaller, saving disk > space. (not a big issue today, but anyhow...) hehe ... be carefull ... setBuffer( [<cBuffer>], [<nFormat>], [<nCompression>] ) space will only be smaller if you use Compression ... im not shure about JPG or PNG in Memo for "other" 3PP Application, if "other" can "read" them while default are Bitmap ( XBPBMP_FORMAT_WIN3X ) > the other options as I said before is build it yourself and save it to a > second memo field (or maybe concatenate to the same one) > the header is : > > "BM" + > length of file (including header - 4 bytes) + > zeros (4 bytes) > hex 36 (or dec 54) (4 bytes) yes we do have a workaround, see PDR 6009 METHOD MyXbpBitmap:GetWindowsFileHeader( nDataLen, nOffset ) Create 14 byte bitmap header 1- 2 2 Byte -> "BM" 3- 6 4 Byte -> File size 7- 8 2 Byte -> Chr(0) 9-10 2 Byte -> Chr(0) 11-14 4 Byte -> Offset image data RETURN "BM" + ; U2Bin( 14 + nDataLen ) + ; U2Bin( 0 ) + ; U2Bin( nOffset + 14) but it is just a Xbase++ Workaround ... how to U2Bin() with WinDev (http://www.windev.com/windev/WD-Express.htm) with Structure like VB or C ? it is realy funny why Xbase++ does not store 1st 14byte of Bitmap when using :setBuffer ... any Sence ? so im waiting for "close(ed) fix" 6009 to be released to use Xbase++ Memo Type "V" with Bitmaps shared with "other" 3PP Application greetings by OHR Jimmy |