Sign in to follow this  
  • entries
    557
  • comments
    1237
  • views
    422057

Untitled

Sign in to follow this  

118 views

Hmm, it's later than I hoped it'd be. I've been abusing GDI+ to support some more file types in my sprite utility.

I don't want to link to gdiplus.lib since that'd require GDI+ is available, and I know it's not on some OSs (Cue someone telling me it's only not available on Windows 98 or something [smile]).

So, my code loads gdiplus.dll, and uses GetProcAddress() to get the address of the functions I need. I get a list of the decoders available on the system, so I can see what file formats are available for the Open File dialog. When a file is opened, I use the Bitmap::FromFile function (Well, DLL export of it) to load the image file, then Bitmap::GetHBITMAP to get a GDI compatible HBITMAP to play with, then I destroy the GDI+ image.

Fun, but probably pointless. But I can now load windows metafiles, JPEGs, PNGs, and so on.

Right, bed time. Office Christmas party tomorrow which could be entertaining. Or dreadul, we'll see.
Sign in to follow this  


1 Comment


Recommended Comments

You're close, it's not available on Windows 2000 and below. :P

Actually...those versions just don't come with the DLL. You can redist the DLL with your app if you want, it's available for download somewhere on MSDN. A few months ago at work I added GDI+ support for the VB6 (teh horror!) app I work on. We still support 2000 though and my manager didn't want to redist the DLL, so the solution was to have all the code that uses it detect whether the DLL was present via a LoadLibrary call and then block off all kinds of functionality if it's not there. What the hell is the point you ask? I don't know.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now