In an earlier topic, I was trying to use CreateBitmap to get a handle for a bitmap.
Japeth gave me some good suggestions and example code which I got to work fine.
Today, I found that this same code run on Windows98 blows up every time.
It runs fine on WindowsXP (both Home and Pro versions]
Here is the code:
Any ideas?
Japeth gave me some good suggestions and example code which I got to work fine.
Today, I found that this same code run on Windows98 blows up every time.
It runs fine on WindowsXP (both Home and Pro versions]
Here is the code:
invoke GetDC,NULL
mov [_ArgSafe0],eax
mov ebx,!bm+14
invoke CreateDIBSection,eax,ebx,0,_ArgSafe1,0,0
mov ,eax
mov edi,[_ArgSafe1]
mov esi,!bm
mov ecx,
mov edx,
sub ecx,edx
add esi,edx
_Lbl2:
mov eax,
mov ,eax
inc esi
inc edi
dec ecx
jne _Lbl2
invoke ReleaseDC,0,[_ArgSafe0]
Any ideas?
Hi mikes!
It's good idea to use simple CreateCompatibleBitmap function.
invoke GetDC, NULL
invoke CreateCompatibleBitmap, eax, nWidth, nHeight
; --- hBitmap in EAX now ---
if you want to access pixel buffer directly - just use GetObject
.data?
BmpStruct BITMAP <?>
.code
invoke GetObject, hBitmap, sizeof(BITMAP), offset BmpStruct
Best regards
...
It's good idea to use simple CreateCompatibleBitmap function.
invoke GetDC, NULL
invoke CreateCompatibleBitmap, eax, nWidth, nHeight
; --- hBitmap in EAX now ---
if you want to access pixel buffer directly - just use GetObject
.data?
BmpStruct BITMAP <?>
.code
invoke GetObject, hBitmap, sizeof(BITMAP), offset BmpStruct
Best regards
...
this fragment:
mov esi,!bm
mov ecx, ;BITMAPFILEHEADER.bfSize
mov edx, ;BITMAPFILEHEADER.bfOffBits
sub ecx,edx
add esi,edx
_Lbl2:
mov eax,
mov ,eax
inc esi
inc edi
dec ecx
jne _Lbl2
may cause a failure, because it moves 3 bytes more than required.
better just use "rep movsb" here instead of the loop
Japheth,
If I subtract 8 from ecx, it no longer blows up on Win98, but there is "junk" at the very top of the image where the map was not completed in the copy.
If I only subtract 3, there is no change from the original code.
It looks to me like Win98 does not allocate enough bytes for the pixels in the CreateDIBSection function.
I should have mentioned it in the first post that 1 bitmap is never a problem... just 2 or more one after another.
If I subtract 8 from ecx, it no longer blows up on Win98, but there is "junk" at the very top of the image where the map was not completed in the copy.
If I only subtract 3, there is no change from the original code.
It looks to me like Win98 does not allocate enough bytes for the pixels in the CreateDIBSection function.
I should have mentioned it in the first post that 1 bitmap is never a problem... just 2 or more one after another.
Is there any way to allow LoadImage to work with memory based bitmaps (not resources)?. If there were, I could get rid of the CreateBitmap/CreateDIBSection I'm having.
Perhaps there is a way to "masquerade" the memory bitmap to look like a resource?
LoadImage works fine for me, but without using resources, I can only use it with files (not memory based bitmaps).
Perhaps there is a way to "masquerade" the memory bitmap to look like a resource?
LoadImage works fine for me, but without using resources, I can only use it with files (not memory based bitmaps).
> I should have mentioned it in the first post that 1 bitmap is never a problem... just 2 or more one after another.
You should post your code as a whole then!
Here is the output of the compiler for the BASIC Program Test1.OBW
This source was compiled for FASM and works fine on WindowsXP, but locks up the whole machine on Windows98.
; Dimension Variables
dim bm1 as bitmap
dim bm2 as bitmap
dim bm3 as bitmap
OBMain.CREATE
createbitmap bm1,OBCNew
createbitmap bm2,OBCOpen
createbitmap bm3,OBCSave1
END EVENT
This source was compiled for FASM and works fine on WindowsXP, but locks up the whole machine on Windows98.
From MSDN:
please note that ppvBits is a pointer to a pointer!
Your code just uses a pointer. I wonder how this could work at all.
HBITMAP CreateDIBSection(
HDC hdc, // handle to DC
CONST BITMAPINFO *pbmi, // bitmap data
UINT iUsage, // data type indicator
VOID **ppvBits, // bit values
HANDLE hSection, // handle to file mapping object
DWORD dwOffset // offset to bitmap bit values
);
please note that ppvBits is a pointer to a pointer!
Your code just uses a pointer. I wonder how this could work at all.
Japheth said:
please note that ppvBits is a pointer to a pointer!
Your code just uses a pointer. I wonder how this could work at all.
Excerpt of Japhaeth's code (last week):
Comparable excerpt of msmith's code:
My code is using the pointer exactly the way your code uses it. Perhaps the problem
is the notation used in FASM vs MASM.
If this is the case, it still does not explain why the code works on XP but not 98.
please note that ppvBits is a pointer to a pointer!
Your code just uses a pointer. I wonder how this could work at all.
Excerpt of Japhaeth's code (last week):
invoke CreateDIBSection, hdc, pBM, DIB_RGB_COLORS, addr pBits, 0, 0
...
mov edi, pBits
Comparable excerpt of msmith's code:
invoke CreateDIBSection,eax,ebx,0,_ArgSafe1,0,0
...
mov edi,[_ArgSafe1]
My code is using the pointer exactly the way your code uses it. Perhaps the problem
is the notation used in FASM vs MASM.
If this is the case, it still does not explain why the code works on XP but not 98.
ok, if it is FASM syntax it is correct (I didn't know that FASM understands "invoke") .
Hi Japheth,
FASM has always had invoke.
I appreciate the help last week and this week from you.
Do you have any idea why the code fails on Win98?
If it is a bug in 98, I would think someone else would have seen it a long time ago.
FASM has always had invoke.
I appreciate the help last week and this week from you.
Do you have any idea why the code fails on Win98?
If it is a bug in 98, I would think someone else would have seen it a long time ago.
> Do you have any idea why the code fails on Win98?
No. For testing I just modified my sample so it calls CreateDIBSection twice. This works on Win98se.