Hi,
While debugging twain, I came across the nativexfer method, used by 60-70% of all twain using programs.
It has some very unfortunate programming logic.
Here is a sample snippet from: http://hp.vector.co.jp/authors/VA011973/prg_twain.htm
TW_UINT16 rc; TW_UINT32 hBitmap; TW_BOOL PendingXfers = TRUE; LPBITMAPINFOHEADER lpDib;
hBitmap = NULL; rc = lpfnDSM_Entry(pAppId,pSourceId,DG_IMAGE,DAT_IMAGENATIVEXFER,MSG_GET,(TW_MEMREF)&hBitmap); lpDib = (LPBITMAPINFOHEADER)GlobalLock((void*)hBitmap); /* ... */ if(lpdib!=NULL){ GlobalUnlock((void*)hBitmap); GlobalFree((void*)hBitmap); }
(hBitmap is the return value of CreateDIBSection()).
This sample code apparently assumes that GlobalLock(HBITMAP) gives it a pointer to a BITMAPINFOHEADER.
We do not do this, for us HBITMAP is a regular 16bit GDI handle. GlobalLock will not work on it :/
Any ideas?
Ciao, Marcus
On Mon, April 24, 2006 3:44 pm, Marcus Meissner said:
We do not do this, for us HBITMAP is a regular 16bit GDI handle. GlobalLock will not work on it :/
Not sure if its related, but this thread: http://www.winehq.org/pipermail/wine-devel/2006-April/thread.html#46804
In particular Alexandre's comment: http://www.winehq.org/pipermail/wine-devel/2006-April/046819.html on handling the 16-bit case in a specific manner.
We may have to do that here as well.
HTH.
On Mon, Apr 24, 2006 at 09:44:50PM +0200, Marcus Meissner wrote:
Hi,
While debugging twain, I came across the nativexfer method, used by 60-70% of all twain using programs.
It has some very unfortunate programming logic.
Here is a sample snippet from: http://hp.vector.co.jp/authors/VA011973/prg_twain.htm
TW_UINT16 rc; TW_UINT32 hBitmap; TW_BOOL PendingXfers = TRUE; LPBITMAPINFOHEADER lpDib;
hBitmap = NULL; rc = lpfnDSM_Entry(pAppId,pSourceId,DG_IMAGE,DAT_IMAGENATIVEXFER,MSG_GET,(TW_MEMREF)&hBitmap); lpDib = (LPBITMAPINFOHEADER)GlobalLock((void*)hBitmap); /* ... */ if(lpdib!=NULL){ GlobalUnlock((void*)hBitmap); GlobalFree((void*)hBitmap); }
(hBitmap is the return value of CreateDIBSection()).
This sample code apparently assumes that GlobalLock(HBITMAP) gives it a pointer to a BITMAPINFOHEADER.
It also expects the DIB bits right behind this header (+ palette), which absolutely does not match our currently DIB memory layouts.
I expect much fun :)
Ciao, Marcus