i'll email you the problematic function tomorrow (and a program skeleton so you can test it without adding a ton of your own code), or if your on MSN i'll add you?
Cheers,
Ste
spot the problem...
Quote:Original post by Sandman
Yes, this is one of the annoying things about GDI, it gives you no feedback as to what's wrong.
Actually on NT/XP/2K a call to GetLastError() generally gives enough information to figure out why the call failed.
Quote:Original post by noNchaoTic
Can anyone see why this isn't working?
1. Do not switch to GetDC() as suggested. The operation you are attempting to perform is not associated with a window DC. CreateCompatibleDC() should be used as it will create a memory DC compatible with the display (rather than being directly owned/associated with the display).
2. You should still use the CreateCompatibleBitmap() as already suggested.
3. If the source bitmap is palettized (256) you may need to set (realize) the palette in the source device context in order for it to be rendered (otherwise the result may be blank or discolored).
4. Since the dimensions of the bitmap are accessible in the BITMAP data structure there's really no reason to pass the width and height - UNLESS you are resizing the image (i.e. 16x16 to 32x32) in which case you need to call StretchBlt
5. Make sure that (BlitX + Width) and (BlitY + Height) do NOT go past the boundries of the source bitmap. Windows only clips against the destination device context.
6. If the bit depth of the image used by Destin does not match the DC the blt calls may fail.
Author
Quote:1. Do not switch to GetDC() as suggested. The operation you are attempting to perform is not associated with a window DC. CreateCompatibleDC() should be used as it will create a memory DC compatible with the display (rather than being directly owned/associated with the display).
I've tried both, and creating a DC from NULL.
Quote:2. You should still use the CreateCompatibleBitmap() as already suggested.
Already done.
Quote:3. If the source bitmap is palettized (256) you may need to set (realize) the palette in the source device context in order for it to be rendered (otherwise the result may be blank or discolored).
Source image is 24 bit, and the destination is using the
Quote:4. Since the dimensions of the bitmap are accessible in the BITMAP data structure there's really no reason to pass the width and height - UNLESS you are resizing the image (i.e. 16x16 to 32x32) in which case you need to call StretchBlt.
Well, I want the function to support copying a portion of the image, so I think thats the best way of doing that? I.e.: copy a rectangle 64x64, starting a BlitX, BlitY... But if you know a better way im open to that for sure. :-)
Quote:5. Make sure that (BlitX + Width) and (BlitY + Height) do NOT go past the boundries of the source bitmap. Windows only clips against the destination device context.
I will add this check, thanks for the info, but I am trying to Copy a chunk 64x64 starting from 0, 0, out of an image 256x256... so shouldn't be this causing the issue.
Quote:6. If the bit depth of the image used by Destin does not match the DC the blt calls may fail.
As the image is being created with the same bitsPerPixel as the original I dont think its this? At least it was, CreateCompatibleBitmap should create a 24 bit image right? If not how can I ensure this?
Thanks.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
