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

[petersen]

I attach two WMF files as requested - one with "placeable" header and one without. A 32-BPP ANI is also included for your ready use.

I myself do not have much knowledge on EMF/WMF, but just enough to handle them (load and save). In view of the lacking of published materials, the following are pertinent to getting a grip of WMF.

I would say WMF is a mess (like many things coming out from MS, e.g. look at ICO header and look at Resource file structure for Cursor versus that for Icon, the original design was so loose). As a result, we got 4 types of it as you said (I would say 5 actually, the 5th one being of a "bitmap" variation rather than GDI commands).

With a "standard" WMF file, what you get from calling GDI+ is basically your screen size. Therefore, it was fully justifiable for Aldus to add a placeable header, in order to establish the intended image size with certainty.

' "Standard" metafile. 18 bytes.
Private Type METAHEADER
mtType As Integer
mtHeaderSize As Integer
mtVersion As Integer
mtSize As Long ' Value of mtSize needs to be "x2", as it is in Words
mtNoObjects As Integer
mtMaxRecord As Long
mtNoParameters As Integer
End Type

' "Aldus Placeable" header
Private Type PLACEABLE
Key As Long
handle As Integer
Left As Integer
TOp As Integer
Right As Integer
bottom As Integer
Inch As Integer
Reserved As Long
Checksum As Integer
End Type

It is because of what is said in the previous paragraph, you will notice that the image returned from your Icon Resource Organizer is distorted, if you load the one without placeable header. For a comparison, you can download a gadget of mine to try the same (where the size is halved intentionally), Like you I am an amateur graphics lover, as such there might be some other materials of referecne value to you in the said gadget. Just unzip it to a temp folder (there are 2 DLLs there, dispensing any or all of them would not affect the program running). (Will remove URL a bit later today).

An explanation of "* 96/120" is in order. On one hand, pixels are a device dependant scalemode, on the other hand, himetric is based on the metric system which is device independent. Therefore, in order to arrive at the same pixel units irrespective of the DPI settings, we have to take into account of the DPI value in converting HiMetric to Pixel.

This morning I purposely powered off and on of my PC and I am able to re-produce all of what I said in my previous posting. However, there is one point I want to bring to your attention: The test results of "a" and "b" of "2" in my previous posting seem to vary on different tries, much depends on what has been loaded previously.