[vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)

[LaVolpe]

What I suspect you are experiencing is a little known behavior of VB.

1) Loading WMF,EMF by handle isn't supported in this version of the control. Just send the picture object.

2) When you load a bmp/jpg by the object, you should not experience any quality issues.

3) When you load GIF by handle, compiled or not, or by object, when compiled, you will lose transparency

4) When you load icon by object, when compiled, you would lose quality if I didn't foresee that problem.

For #3 & #4 above, here is why. During design-time, uncompiled project, VB caches the original image data when it creates a stdPicture object. I believe this is simply so that VB can save the original data with the project in the .frx, ctx, and other project files. But when your project is compiled, VB does not save this data any longer when it creates the stdPicture object, it doesn't need to, for its purposes, because it knows that data is not needed for saving to project files.

Ok? When you pass the picture object to be loaded, my control's logic works like this:

1) Icon? Always load by the object's Handle to avoid VB's color reduction

2) Anything else: If VB kept the original data, use that data to load the image (as mentioned VB doesn't save this data when compiled)

3) If no original data exists, code asks VB to create the data. This is where VB is really bad with icons and GIFs. GIFs/JPGs are saved in bitmap format. GIFs lose transparency because internally by VB/COM, they are bitmaps not GIFs. Icons are color reduced down to 16 colors resulting in poor quality. You should see these quality issues if you viewed the result of the image file created by VB with: SavePicture "c:\test images\filename.ext", Image1

Note: Even if the original metafile data is not provided in the picture object, VB can recreate metafiles flawlessly

This behavior of VB needs to be understood if passing picture objects to anything, to be used as image source data.

Suggestions if these formats will be used by the alpha image control (AIC) after your project is compiled:
1) GIFs. Load these into a resource file. Pass them via LoadResData()
:: doing so, ensures all frames are available & transparency is preserved
2) Icons. Same as GIFs. You could also use VB's image control since the AIC uses the icon handle
:: using res file ensures all sub-icons are available if more than 1 icon exists
3) Bitmaps. Any method you want
:: stdPicture objects processed by ignoring alpha channel. If channel is used, pass by handle
4) JPGs. Load these via resource file if the original image data is needed by you. Otherwise, any method will work
:: saving a JPG loaded by VB to JPG format causes recompression of original data
5) WMF/EMF. Any method you want, but don't try to load metafiles by handle
:: see notes below
6) Any format not supported by VB: use the resource file method or disk file

Edited: I see you use this quite a bit: LaVolpeAlphaImg.AICGlobals....
Just FYI, shouldn't be necessary if you don't want to: Set AlphaImgCtl1.Picture = LoadPictureGDIplus(Image1.Picture)

Edited Again. A bit more about metafiles if trying to pass by handle
EMFs can be processed a couple different ways from its handle. This is not a major issue to support passing EMF by handle. However, WMFs are a different story...

When you have a WMF handle, you have a handle to its bits, its drawing commands. Without analyzing each command to determine where & what dimensions each command is attempting to draw to, there is no way I can think of to get the dimensions, nor aspect ratio of a WMF strictly from its handle. With the handle only, what we have is basically a non-placeable WMF -- no dimensions, no aspect ratio. In my own version of this control, WMFs passed by handle are treated as non-placeable and user has option to set dimensions. GetObjectType API helps identify type of image handle.