Printable View
This is strange. I'm using code I've seen online.
When I GetLastError, it returns #8, ERROR_NOT_ENOUGH_MEMORY. The pathname is "C:\\4by4bitmap.bmp". It is a 24 bit bitmap. I'm using Windows XP. I saw that someone online had a similar problem, but the website listed no solution.Code:m_bitmap = (HBITMAP)::LoadImage(0 ,pathname,IMAGE_BITMAP,0,0,LR_LOADFROMFILE|LR_CREATEDIBSECTION);
Anyone have any ideas about this?
Maybe the error is correct.Quote:
Originally Posted by paradoxresolved
We know nothing about this bitmap except the name you stated. What are the dimensions of this bitmap? What does an image editor say are the dimensions? How about hard-coding the filename in your call to LoadImage() to ensure you're loading the correct file?
Regards,
Paul McKenzie
Did you actually try loading it into resource ?
Thanks for the response.
It's a 24-bit 159 by 160 bitmap. It just looks like a simple colored checkerboard. It's the same one as seen in the thread "Dynamic bitmap creation". (I don't know how to make a link to it, sorry :( )
I'm not trying to make it a resource. I need a function that calls for loading bitmaps from a file, and I have no idea why it's running out of memory. If my machine is capable of rendering graphic intense games, it shouldn't have the slightest trouble with a small bitmap. That is why I'm puzzled.
Is this the wrong strategy for loading an image into memory?
Edit: The pathname actually is temporarily hard-coded elsewhere in a function that calls LoadImage. If the pathname was incorrect, wouldn't it give me a different error entirely?
The most recent user contribution to the MSDN doc on LoadImage() happens to report the exact same problem, unfortunately yet without a solution posted although it dates back to 12/23/2010.
The following is just a hint, but perhaps it leads into the right direction...
As per my experience with the .NET framework, its bitmap handling methods from the classes in the System::Drawing namespace (which are wrappers for GDI+ functionality) use to throw an OutOfMemoryException in case of problems handling the bitmap format in any way. I also noticed that these errors are less frequent on Win7 compared to XP which seems to indicate that the Win7 GDI+ routines are more flexible in that respect (which AFAIK is undocumented). And that's what the user comment linked to above also reports: It does work under 7.
For reference, here's a related thread in the C++/CLI section: http://www.codeguru.com/forum/showthread.php?t=513030. But be warned: It's long... :D
Going by what Eri523 stated, maybe the problem is the 159, i.e. the bitmap scan lines are not DWORD-aligned, and LoadImage has trouble handling such images.Quote:
Originally Posted by paradoxresolved
If you could use a bitmap editor and saved the image as 160x160, could you load it then using LoadImage?
Regards,
Paul McKenzie
Sadly, 160 by 160 did not fix it. :(
What I'm hearing is that this is the end of the road for LoadImage and WinXP. I originally designed the function with Visual C++ 6.0 and had no problems. I'm not sure what has changed, but I'm starting to miss that ol' hoss. . .
In light of this difficulty, are there any other methods I can use to load a bitmap into memory from a file?
I'll start looking through the other post as well.
Thanks for the info so far.
There are literally thousands of code snippets, examples, libraries, etc. that shows you how to load a BMP file to memory without calling LoadImage().Quote:
Originally Posted by paradoxresolved
I'm surprised you can't find anything, as loading a BMP into memory is one of the basic things any image program would be able to do (without calling LoadImage). Most, if not all imaging libraries just read the BMP file, put together the BMP header, and reads the data. Again, code that does that can be found all over the net, maybe you have a routine right now you never knew you had.
Regards,
Paul McKenzie
Have you tried the LR_DEFAULTSIZE flag?
Paul: Yes, I'm afraid you're right. I've learned coding from the School of Hard Knocks. LoadImage worked in the day, so I left it at that. I'll have a look at what's out there.
Arjay: I tried the flag and it still doesn't work. :(
Just to try to narrow any problems, I tried the following code:Code:m_bitmap = (HBITMAP)::LoadImage(0,pathname,IMAGE_BITMAP,0,0,LR_LOADFROMFILE|LR_CREATEDIBSECTION|LR_DEFAULTSIZE);
Where MainImage is a picture control. With that I get 0 for the error, but the bitmap still does not appear. The "Auto" tab in Visual Studio 2010 lists m_bitmap as 0x18050f43 {unused=??? ). IDB_BITMAP1 is sitting there in the resources. It's the same 160 by 160 bitmap.Code:HBITMAP m_bitmap = (HBITMAP)::LoadBitmap(AfxGetInstanceHandle(), MAKEINTRESOURCE(IDB_BITMAP1));
DWORD error = GetLastError();
/* DEBUGGING BREAK POINT POSITIONED AT FOLLOWING 'IF'*/
if(m_bitmap)
MainImage.SetBitmap(m_bitmap);
else
MessageBox("Failed to load bitmap");
MainImage.Invalidate();
MainImage.RedrawWindow();
While it doesn't solve the loading from file issue, is there anything wrong with this code? I'd like to narrow variables here.
Can you post the bitmap you are trying to load?
It is posted in the thread "Dynamic bitmap creation". I don't know how to make links in this forum. Sorry :(
The funny thing is that I never would even consider LoadImage() to load a BMP -- to be honest, it wouldn't even enter my mind, as there are so many examples showing you how to read BMP files directly. Code to read BMP files without LoadImage have been around, at least since Windows 2.x, and most of these routines have remained virtually unchanged since those days (and probably still work).Quote:
Originally Posted by paradoxresolved
Granted, without samples, it is difficult to do, but once you get a few samples, it becomes relatively easy -- most of them follow the same pattern (read the file header, set up the BITMAPINFOHEADER struct with the data, read the image data, etc.). Some samples would add aligning the unaligned BMP's (the good samples do this), and maybe correct some other wrinkles that may be in a BMP file.
Regards,
Paul McKenzie
At least Windows Image and Fax Viewer, Paint and FastStone Image Viewer open the file properly and don't reveal any oddities. Had no time to pick it apart with the hex editor and/or my own code yet, though.Quote:
Originally Posted by paradoxresolved
At any rate, here's the link to the thread where the image has been attached (for other readers): http://www.codeguru.com/forum/showthread.php?t=514930 (simply copy-pasted from the address line of my browser)
Paul: I found a few sites that explain the process, so I'll have a go at that shortly. Thanks for the nudge out the door. :)
Eri523: Now I know how to link other threads. Grats!:)