FireImage Control in FireSplitter Control Problem

[José Roca]

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.

[Roger Garstang]

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.

[Paul Squires]

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.

[Roger Garstang]

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?

[Paul Squires]

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.

[Paul Squires]

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