CreateBitmap returns 0, Err.LastDllError also

CreateBitmap returns 0, Err.LastDllError also

Post by Sinn » Wed, 25 Oct 2006 22:34:01


Hi,

I'm facing an issue I don't know how to solve.

If I call the CreateBitmap API function with width 480 and height 640,
the return value is 0. Err.LastDllError() also returns 0.

This is the code:

Private Declare Function CreateBitmap Lib "gdi32.dll" ( _
ByVal nWidth As Long, ByVal nHeight As Long, _
ByVal nPlanes As Long, ByVal nBitCount As Long, _
lpBits As Any) As Long


(...)

hBMMask = CreateBitmap(480&, 640&, 1&, 1&, 0&)


What goes wrong? For smaller sizes it succeeds.


Sinna
 
 
 

CreateBitmap returns 0, Err.LastDllError also

Post by Thorsten A » Thu, 26 Oct 2006 00:05:14

Sinna < XXXX@XXXXX.COM > schrieb im Beitrag
<# XXXX@XXXXX.COM >...

Try
hBMMask = CreateBitmap(480, 640, 1, 1, ByVal 0&)
instead!

BTW: It is not necessary to add the long data type suffix to the numbers
passed as the first 4 parameters!

--
----------------------------------------------------------------------
THORSTEN ALBERS Universit Freiburg
albers@
uni-freiburg.de
----------------------------------------------------------------------

 
 
 

CreateBitmap returns 0, Err.LastDllError also

Post by Karl E. Pe » Thu, 26 Oct 2006 01:46:18


What leads you to assert that? I've heard folks (who I respected) say that
doing so avoids the coercion from simplest representative datatype (Integer)
to proper (Long). Not that this should have much impact, granted. I've
never looked at the compiled ASM for this, though.
--
Working without a .NET?
http://www.yqcomputer.com/
 
 
 

CreateBitmap returns 0, Err.LastDllError also

Post by Thorsten A » Thu, 26 Oct 2006 06:42:36

Karl E. Peterson < XXXX@XXXXX.COM > schrieb im Beitrag
< XXXX@XXXXX.COM >...
that
(Integer)

In general we surely do agree that using integer values with this function
for the first 4 parameters will never lead to any problems since the signed
integer can be casted to a signed long without any problems (omitting that
negative values aren't allowed to be passed here at all...). If the VB
compiler isn't optimized, there might be a very slight performance
advantage when using the long data type suffix. If it is optimized, it
stores the constants used in this context already internally as long
values. Personally I am assuming that the latter is the case. But I haven't
seen the compiled ASM either. On the other hand, if the suffix is used,
there maybe is one thing more to be fixed when the code has to be ported to
another VB version or programming language.
Of course here I would neither use the suffixed long nor integer values but
declared constants (then of course declared "As Long").

--
----------------------------------------------------------------------
THORSTEN ALBERS Universit Freiburg
albers@
uni-freiburg.de
----------------------------------------------------------------------
 
 
 

CreateBitmap returns 0, Err.LastDllError also

Post by Karl E. Pe » Thu, 26 Oct 2006 06:57:57


I'm trying hard to remember who slapped me for this, and the name that keeps
coming back to me is Matt Curland. Anyone interested in
decompiling/interpreting this? <g>


Yep.


That's always a good answer, too. :-)
--
Working without a .NET?
http://www.yqcomputer.com/
 
 
 

CreateBitmap returns 0, Err.LastDllError also

Post by Sinn » Thu, 26 Oct 2006 15:15:44


Thanks Thorsten,

That solved the problem.
Quite strange that it did succeed for smaller sizes! Never thought it
would be the declaration.


Sinna
 
 
 

CreateBitmap returns 0, Err.LastDllError also

Post by Karl E. Pe » Fri, 27 Oct 2006 01:17:11


Size isn't likely the issue, at all. Check the docs about passing NULL in
that last parameter. Understanding that point, passing null pointers, is
*key* to a great number of API calls. Previously, you were just passing a
pointer to some random chunk of memory.
--
Working without a .NET?
http://www.yqcomputer.com/
 
 
 

CreateBitmap returns 0, Err.LastDllError also

Post by Mike D Sut » Fri, 27 Oct 2006 03:40:25

> That solved the problem.

For anything up to an 32*1 or 16*2 buffer it's perfectly valid since a DWord holds enough storage space to describe the
entire data buffer at 1-BPP, however any larger than that and the API has to read off the end of the variable into
no-man's land. Depending on how the temporary variable memory is structured, this could very well be reading into
memory that's protected by the system or allotted to another process and the call falls over.
Hope this helps,

Mike


- Microsoft Visual Basic MVP -
E-Mail: XXXX@XXXXX.COM
WWW: http://www.yqcomputer.com/