icons.htm

各种文件格式说明及程序描述

{
wsprintf( szbuffer, "%d", dwnewsize );
regsetvalueex( hkey, "shell icon size", 0, reg_sz, szbuffer,
lstrlen(szbuffer) + 1 );
}
// clean up
regclosekey( hkey );
// let everyone know that things changed
sendmessage( hwnd_broadcast, wm_settingchange, spi_seticonmetrics,
(lparam)("windowmetrics") );
return dwoldsize;
#undef max_length
}
</font></pre>
<h3><b>table 1. where windows uses different sized icons</b></h3>
<table width="87%" border="1" cellpadding="5" cellspacing="0">
<tr valign="top" bgcolor="#dddddd">
<td><font face="verdana, arial, helvetica, sans-serif" size="2">location</font></td>
<td><font face="verdana, arial, helvetica, sans-serif" size="2">icon size</font></td>
</tr>
<tr>
<td></font><font size="2">　</font><font face="verdana, arial, helvetica, sans-serif"
size="2"></td>
</tr>
<tr valign="top">
<td><font face="verdana, arial, helvetica, sans-serif" size="2">desktop</font></td>
<td><font face="verdana, arial, helvetica, sans-serif" size="2">shell large</font></td>
</tr>
<tr>
<td></font><font size="2">　</font><font face="verdana, arial, helvetica, sans-serif"
size="2"></td>
</tr>
<tr valign="top">
<td><font face="verdana, arial, helvetica, sans-serif" size="2">titlebar of windows</font></td>
<td><font face="verdana, arial, helvetica, sans-serif" size="2">system small</font></td>
</tr>
<tr>
<td></font><font size="2">　</font><font face="verdana, arial, helvetica, sans-serif"
size="2"></td>
</tr>
<tr valign="top">
<td><font face="verdana, arial, helvetica, sans-serif" size="2">&lt;alt&gt;&lt;tab&gt;
dialog</font></td>
<td><font face="verdana, arial, helvetica, sans-serif" size="2">system large</font></td>
</tr>
<tr>
<td></font><font size="2">　</font><font face="verdana, arial, helvetica, sans-serif"
size="2"></td>
</tr>
<tr valign="top">
<td><font face="verdana, arial, helvetica, sans-serif" size="2">start menu</font></td>
<td><font face="verdana, arial, helvetica, sans-serif" size="2">shell small / shell large</font></td>
</tr>
</table>
<p>while windows imposes no restrictions on the sizes of icons, common sizes include 16,
32, and 48 pixels square. for this reason, developers are encouraged to include a minimum
of the following sizes and color depths in their icon resources: </p>
<table width="87%" border="1" cellpadding="5" cellspacing="0">
<tr valign="top" bgcolor="#dddddd">
<td><font face="verdana, arial, helvetica, sans-serif" size="2">16 x 16</font></td>
<td><font face="verdana, arial, helvetica, sans-serif" size="2">16 colors</font></td>
</tr>
<tr>
<td></font><font size="2">　</font><font face="verdana, arial, helvetica, sans-serif"
size="2"></td>
</tr>
<tr valign="top">
<td><font face="verdana, arial, helvetica, sans-serif" size="2">32 x 32</font></td>
<td><font face="verdana, arial, helvetica, sans-serif" size="2">16 colors</font></td>
</tr>
<tr>
<td></font><font size="2">　</font><font face="verdana, arial, helvetica, sans-serif"
size="2"></td>
</tr>
<tr valign="top">
<td><font face="verdana, arial, helvetica, sans-serif" size="2">48 x 48</font></td>
<td><font face="verdana, arial, helvetica, sans-serif" size="2">256 colors</font></td>
</tr>
</table>
<h3>choosing an icon</h3>
<p>when windows prepares to display an icon, a desktop shortcut for example, it must parse
the .exe or .dll file and extract the appropriate icon image. this selection is a two step
process starting with the selection of the appropriate rt_group_icon resource, and ending
with the selection of the proper rt_icon image from that rt_group_icon.</p>
<h4>which icon?</h4>
<p>if an .exe or .dll file has only one rt_group_icon resource, the first step is trivial;
windows simply uses that resource. however, if more than one such group resource exists in
the file, windows must decide which one to use. windows nt simply chooses the first
resource listed in the application's rc script. on the other hand, windows 95's algorithm
is to choose the alphabetically first named group icon if one exists. if one such group
resource does not exist, windows chooses the icon with the numerically lowest identifier.
so, to be sure that a particular icon is used for an application, the developer should
insure that both of the following criteria are met:<ol>
<li>the icon is placed before all other icons in the rc file. </li>
<li>if the icon is named, its name is alphabetically before any other named icon, otherwise
its resource identifier is numerically smaller than any other icon. </li>
</ol>
<h4>which image?</h4>
<p>once an rt_group_icon is chosen, the individual icon image, or rt_icon resource, must
be selected and extracted. again, if there exists only one rt_icon resource for the group
in question, the choice is trivial. however, if multiple images are present in the group,
the following selection rules are applied:<ol>
<li>the image closest in size to the requested size is chosen. </li>
<li>if two or more images of that size are present, the one that matches the color depth of
the display is chosen.</li>
<li>if none exactly match the color depth of the display, windows chooses the image with the
greatest color depth without exceeding the color depth of the display.</li>
<li>if all the size-matched images exceed the color depth of the display, the one with the
lowest color depth is chosen. </li>
<li>windows treats all color depths of 8 or more bpp as equal. for example, it is pointless
to have a 16x16 256 color image and a 16x16 16bpp image in the same resource--windows will
simply choose the first one it encounters. </li>
<li>when the display is in 8bpp mode, windows will prefer a 16 color icon over a 256 color
icon, and will display all icons using the system default palette. </li>
</ol>
<h2>apis</h2>
<p>when dealing with icons, the developer can choose to manipulate the raw resource bytes,
or let windows handle the low level details and simply use hicon handles. the advantage of
handling the raw resource bytes is a gain in control, while the advantage of using the
hicon handles is that of simplicity. for most purposes, the hicon interface is
sufficient--it is likely that handling the raw resource bytes will be necessary only in
the development of an icon handling program.</p>
<h3>raw resource bytes</h3>
<p>the standard windows api functions for manipulating resources--<b>findresource()</b>, <b>loadresource()</b>
and <b>lockresource()</b>--can, of course, be used to handle icon resources.</p>
<p><b>enumresourcenames()</b> can be used, passing in rt_group_icon, to find the available
group icon resources. once the appropriate group resource is chosen, it can be loaded
using <b>findresource()</b>, <b>loadresource()</b> and <b>lockresource()</b>. this will
yield a pointer to a grpicondir structure.</p>
<p>the <b>identries</b> array is the searched for a match on the desired color depth and
size. the <b>nid</b> member of that array element is then used as an argument to <b>findresource()</b>,
passing in rt_icon. <b>loadresource()</b> and <b>lockresource</b> then yield a pointer to
an iconimage structure for that icon image.</p>
<p>to allow windows to perform the color depth and size selection, the grpicondir
structure can be passed to <b>lookupiconidfromdirectory()</b> or l<b>ookupiconidfromdirectoryex()</b>.
both of these functions return an id that can be used with rt_icon and findresource(), the
latter providing a way to specify a desired size to match against. </p>
<p>the iconimage structure contains pointers to the dib bits for the masks. these pointers
can be used in dib functions for direct manipulation. the iconimage structure is also
conveniently suitable to be passed to <b>createiconfromresource()</b> or <b>createiconfromresourceex()</b>
to yield an hicon handle. the former of the two functions creates an icon that is system
large size. the latter provides a way to specify a desired size, and windows performs the
appropriate conversions. </p>
<h3>hicon handles</h3>
<p>an hicon handle is a handle to a single icon image. this is analogous to a single
rt_icon resource. the image is stored internally using device dependent bitmaps (ddbs).
this implies that all hicon icons have the same color format as the display device. the
size of the icon depends on its origin and the system defined icon sizes.</p>
<p>the available icon handling functions can be thought of in two groups--those that
handle system large size icons and those that handle any size icons. the functions that
handle only system large size icons are typically left over from 16 bit days, when the
system defined only one icon size. the newer functions, those that handle any size icon,
accept as a parameter the desired size of the icon.</p>
<h4>one size fits all</h4>
<p>the original icon handling functions were designed for a system that defined only one
icon size. therefore, most of those functions are unaware of the possibility of more than
one icon size and assume all icons are system large size.</p>
<p><b>loadicon()</b>, <b>extracticon()</b> and <b>drawicon()</b> fall into this category. <b>loadicon()</b>
and <b>extracticon()</b> always search for a match for system large size. if an exact
match cannot be found, these two functions stretch the closest match to that size. they
always return an icon of system large size. similarly, <b>drawicon()</b> always draws the
icon at system large size. if a different size icon is passed to <b>drawicon()</b>, it is
stretched and displayed at system large size.</p>
<p><b>createiconfromresource()</b> also exhibits this behavior. it returns a handle to a
system large size icon, stretching the rt_icon resource it was passed as necessary.</p>
<h4>to each their own</h4>
<p>now that windows has the ability to handle different sized icons, new api functions
were added to handle them. in some cases, old functions were expanded and &quot;ex&quot;
was added to their name. in other cases, whole new functions were added. the net result is
that there is now full support for different sized icons in the windows api.</p>
<p>several different functions are available to get an hicon handle to a different sized
icon. <b>loadimage()</b> can be used to extract an icon from an exe or dll file without
the hassle of manually loading the resource bytes. <b>createiconfromresourceex()</b> is
available if the resource bytes have been loaded.</p>
<p><b>createicon()</b> and <b>createiconindirect()</b>, even though they have their roots
in 16-bit land, do facilitate creating icons of different sizes. <b>createicon()</b>
accept a desired width and height as parameters, while <b>createiconindirect()</b> creates
an icon based on the bitmaps in the iconinfo parameter. note that both of these functions
work with ddbs, not dibs.</p>
<p><b>shgetfileinfo()</b> can also be used to get icons from files, providing the icon
that the shell would display for the file. <b>shgetfileinfo()</b> works on any type of
file, and can extract any of the four icons sizes, as shown below:</p>
<pre><font face="courier" size="2">// load a system large icon image
shgetfileinfo( szfilename, 0, &amp;shfi, sizeof( shfileinfo ),
shgfi_icon | shgfi_largeicon);

// load a system small icon image
shgetfileinfo( szfilename, 0, &amp;shfi, sizeof( shfileinfo ),
shgfi_icon | shgfi_smallicon);

// load a shell large icon image
shgetfileinfo( szfilename, 0, &amp;shfi, sizeof( shfileinfo ),
shgfi_icon | shgfi_shelliconsize);

// load a shell small icon image
shgetfileinfo( szfilename, 0, &amp;shfi, sizeof( shfileinfo ),
shgfi_icon | shgfi_shelliconsize | shgfi_smallicon);
</font></pre>
<p>given an hicon handle, drawiconex() can be used to display it--at its normal size, at
the system large size, or at any other size:</p>
<pre><font face="courier" size="2">// draw it at its native size
drawiconex( hdc, nleft, ntop, hicon, 0, 0, 0, null, di_normal );

// draw it at the system large size
drawiconex( hdc, nleft, ntop, hicon, 0, 0, 0,
null, di_defaultsize | di_normal );

// draw it at some other size (40x40 in this example)
drawiconex( hdc, nleft, ntop, hicon, 40, 40, 0, null, di_normal );
</font></pre>
<p>note that drawiconex() will stretch the icon as necessary to make it fit the desired
output size.</p>
<h4>what's in there?</h4>
<p>the win32 api provides a function for determining the characteristics of an icon, given
its hicon handle. this function is <b>geticoninfo()</b>. <b>geticoninfo()</b> fills out an
iconinfo structure with the information pertaining to the hicon. the iconinfo structure
contains the following information:</p>
<pre><font face="courier" size="2">typedef struct _iconinfo { // ii

bool    ficon;   // true for icon, false for cursor
dword   xhotspot;   // the x hotspot coordinate for cursor
dword   yhotspot;   // the y hotspot coordinate for cursor
hbitmap hbmmask;   // handle to monochrome and mask bitmap
hbitmap hbmcolor;   // handle to device dependent xor mask bitmap
} iconinfo;
</font></pre>
<p>given this information, an application can calculate the information needed to write
the icon to a file. the and mask and xor mask dib bits can be obtained with calls to <b>getdibits()</b>
on the two bitmaps in this structure.</p>
<h2>a word on cursors</h2>
<p>cursors, in win32, are very similar to icons. in fact, by changing only one line in the
source code for iconpro, that sample can read .cur files. iconpro currently tests the <b>idtype</b>
member of the icondir structure to make sure the file is an icon file. this check can be
relaxed to allow the type for cursors (2) as well. also, hcursor handles can be used
interchangeably with hicon handles in most win32 icon apis.</p>
<h2>conclusion</h2>
<p>although the icon specification has long been able to handle icons of odd sizes and
color depths, only recently has windows responded with inherent support for such images.
developers now have the option of dealing directly with the bits of an icon, or allowing
windows to handle all the details. windows even provides api support for loading and
displaying icons of non-standard sizes and different color depths. </p>
<p><!--docfooterstart--> </font><font face="verdana, arial, helvetica, sans-serif" size="1">&copy; 1997
microsoft corporation. all rights reserved. legal notices </font><!--docfooterend--> </td>
<td width="10"></td>
</tr>
</table>
<p align="center"><a href="../index.htm">返回</a></p>
</body>
</html>