Paul,
It may be my miss understanding but I am having a problem
getting a jpg file to display in a Fireimage control when that
control in located on a form displayed in a FireSpliter Control.
Note the image displays in the FF editor.
I have attached a small project that demostrates the problem.
Where am I going wrong?
Marty,
I ran your project and can see ASlogo.JPG in Form3.
I ran both your compiled exe and a fresh compile on my pc.
Interesting...
What version of windows are you using?
I am using Windows-7.
Maybe it's a Windows specific problem.
I have an old XP computer. I will try it on that.
Windows XP SP3
AMD Athlon64 X2 5200+
4 GB RAM
nVidia 8800 GTS 320 MB
nVidia Driver 191.07
Marty,
works fine with me. Same configuration as Cho Sin Kum.
On my Win7 laptop I can't see the graphic but on my WinXP computer I can see it. Weird.
Windows 7 Ultimate Release Candidate:
Form4 shows the graphic.
Form3 does not.
The grpahic on Form4 is a standard picture control with a bitmap. The graphic on Form3 is the FireImage control with a jpg - that is the one that does not show when viewed in Win7. I will try something later that may be related to the problem - it may be a long shot but you never know.
Paul, Any idea why the JGP won't show?
Not yet. I have done very little programming over Christmas.
Any ideas about this jpg image display problem?
Based on the few tests that I have run, the images work perfectly when loaded from a disk file but fail when loaded from the resource file. This is why in Win7 you see the image in the FireFly designer because FF loads the image from disk. In the compiled exe the image is attempted to be loaded from the resource file.
I now need to determine why loading from the resource file fails on Win7 but not on WinXP.
Looks like at least someone else is having the same problem: http://stackoverflow.com/questions/1902987/gdipcreatebitmapfromstream-change-of-contract-on-windows-7
"We have a perfectly functional app that just broke on Windows 7 because (the GDI+ primitive) GdipCreateBitmapFromStream refuses JPEG images presented to it (without problem on XP and even Vista)."
Granted, the code they are using is C++ and it means mostly gibberish to me.
Here is the response post which I guess provides a solution:
"Further research reveals that W7 queries an additional optional interface on the stream, and it's essential to return E_NOINTERFACE instead of E_NOTIMPL for it."
Now, if only I had half a clue what that means....... :)
Haven't done much with Classes/COM/Interfaces even though PB now supports it. Sounds like another Interface expecting that type is needed. Out of my area, although I plan to know more on it at some point. Isn't stuff like that Jose's area? He probably already has something for it.
The majority of the code is from Jose's image controls from his site. Everything worked perfectly until Windows 7. Bummer.
Sorry, but I don't have Windows 7. The fact is that GdipCreateBitmapFromStream is intended to work with streams stored in compound files, not with a global memory stream. Maybe Windows 7 wants some information available in the compound file implementation of streams, but I really don't know. There is a GDI+ function called GdipCreateBitmapFromResource that should work, although it requires bitmaps, not JPGs.
Hmm, if that is the case, perhaps he could just extract the resource to temp file. There are a couple API functions to get the temp folder and even generate a unique temp name. Could even set the FILE_ATTRIBUTE_TEMPORARY and FILE_FLAG_DELETE_ON_CLOSE flags in the call to CreateFile the file so once done it is deleted and temp file markings make it handle better and try to keep in memory for faster access.
Quote from: Roger Garstang on January 14, 2010, 07:19:17 PM
Hmm, if that is the case, perhaps he could just extract the resource to temp file. There are a couple API functions to get the temp folder and even generate a unique temp name. Could even set the FILE_ATTRIBUTE_TEMPORARY and FILE_FLAG_DELETE_ON_CLOSE flags in the call to CreateFile the file so once done it is deleted and temp file markings make it handle better and try to keep in memory for faster access.
That is exactly what I am doing. I have it all coded except for the deleting of the temp file. I should finish that tomorrow. There is hardly any performance loss by saving to the disk file first. This is a good compromise and should also solve Jean-Pierre's problem he had with displaying certain graphics via a string retrieved from a database.
I will post the new FireImage control once it is debugged.
Do you pass the function the file handle where the FILE_FLAG_DELETE_ON_CLOSE flag would work? I've always wanted to use that flag, but never had a function that would take a handle and when done close it to see the file get deleted automatically. Probably would still want to check for it being deleted anyway since we all know how good temp files get cleaned up by M$ so it would defeat the purpose, but it sounds like a cool flag.
And, will it only do this with Vista/7+ or all OS?
I decided to stay away from FILE_FLAG_DELETE_ON_CLOSE because I didn't want to have to include the native winapi file handle routines. Using the PB functions were easier. I manually track the three temp file names and delete them whenever the picture(s) change or when the control is destroyed.
BTW, if you haven't seen the post about the new files, it is here: http://www.planetsquires.com/protect/forum/index.php?topic=2295.msg17933