🚀 go-pugleaf

Mike Collins wrote:

>Image->Picture->Icon->Handle      = LoadImage(hDLL, MAKEINTRESOURCE(12), 
>IMAGE_ICON, 32, 32, LR_DEFAULTSIZE);

It doesn't sound like LR_DEFAULTSIZE is compatable with 32,32.
You are asking for exclusive 32,32 icons.
If you used 0,0 with LR_DEFAULTSIZE, you would get 16,16 or SM_CXICON
If you used 0,0 *Without* LR_DEFAULTSIZE, you would get whatever is
available.


>- is it necessary to free the handle that is returned from LoadImage using 
>DestroyIcon?  I never seem any reference to this when i've seen BCB examples 
>and i've never had any resource leaks reported...

No, but its nice to do. From MSDN:

When you are finished using a bitmap, cursor, or icon you loaded
without specifying the LR_SHARED flag, you can release its associated
memory by calling one of the functions in the following table. 
The system automatically deletes these resources when the process that
created them terminates; however, calling the appropriate function
saves memory and decreases the size of the process's working set.

So, not a leak, but uses more memory until freed.

>Secondly, is there any advantage to using LoadImage api over ExtractIcon? 

LoadImage has more options. And can share loaded resources. And can
select best-fit images from multi-size/colordepth icons.
ExtractIcon has no options nor "best-fit".

> To avoid any possible copyright issues,

To avoid copyright issues, make your own icons.

> However, LoadImage seems to fail if i try 
>to load an icon that has an Id grater than 56.

Mine stops at 54 (XP home, SP2)

ExtractIcon works for the full number of icons.

If anyone wants to play with it, compile as console app.
To switch from ExtractIcon to LoadImage, uncomment the 4 lines, and
comment the ExtractIcon.

#include	<windows.h>
	extern	HINSTANCE	_hInstance;	// global in c0x32
/* ---------------------------------------------------------------- */
void _stdcall ErrorBox( HWND hWnd, DWORD errorcode,LPCTSTR titl)
{	VOID* lpBuffer;
	FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER+FORMAT_MESSAGE_FROM_SYSTEM+70,
		NULL,errorcode,0,(char*)&lpBuffer,0,NULL);
	MessageBox( hWnd, (char*)lpBuffer, titl,
		 MB_OK|MB_ICONINFORMATION|MB_TOPMOST );
	LocalFree( lpBuffer );
}
/* ---------------------------------------------------------------- */
int main(void)
{
    int	i;
    int	max = (int)ExtractIcon( _hInstance,
			"C:\\Windows\\system32\\shell32.dll", -1 );
    HICON	hIcon;
    HWND	hWnd = 0;
    char	msg[1024];
//  HMODULE	hMod = GetModuleHandle(
//			 "C:\\Windows\\system32\\shell32.dll" );
    for( i = 1; i <= max; ++i )
    {
//	hIcon = LoadImage( hMod, MAKEINTRESOURCE(i), IMAGE_ICON,
//			 0,0, LR_DEFAULTCOLOR | LR_SHARED );
	hIcon = ExtractIcon( _hInstance,
		 "C:\\Windows\\system32\\shell32.dll", i );
	if( (int)hIcon > 1 )
	{
		wsprintf( msg, "\r\nIcon Test #%i of %i\r\n", i, max);
		ShellAbout ( hWnd, "Icon Tester#About IconTest",
// title bar and first line text
			msg,	// other dialog text
			hIcon ); 	// icon to display
		DestroyIcon( hIcon );
	}else{
		ErrorBox( hWnd, GetLastError(), "LoadImage Error" );
	};
    };
    return 0;
}

"Mike Collins" <its@TheBottomOfThePost.com> wrote in message
news:44f6ea84$1@newsgroups.borland.com...

> Image->Picture->Icon->Handle = LoadImage(hDLL,
> MAKEINTRESOURCE(12), IMAGE_ICON, 32, 32,
> LR_DEFAULTSIZE);

You must specify 0 for the cxDesired and cyDesired parameters if you use the
LR_DEFAULTSIZE flag.  This allows the OS to decide which dimensions to load
from the image based on the current display settings.

> is it necessary to free the handle that is returned from
> LoadImage using DestroyIcon?

Yes, but you do not have to do it yourself.  TIcon takes ownership of the
HICON and will free it for you when the TIcon itself is freed, or if you
assign a new HICON to it.

> i'm having a problem using LoadImage to load icons from shell32.dll.  To
> avoid any possible copyright issues, i'm loading some Windows icons
directly
> from \\system32\\shell32.dll, using exactly the same code as above.
However,
> LoadImage seems to fail if i try to load an icon that has an Id grater
than 56.

Without actually seeing the icons for your copy of shell32.dll, my guess
would be that the icons at those higher IDs don't have 32x32 versions
available for them.  You have hard-coded the cxDesired and cyDesired
parameters to always load 32x32 images only.

Which exact IDs are you trying to load?  For example, in my copy of
shell32.dll on Win98, there are no icon groups available between IDs 47-132.


Gambit

Still can't get it to work.  I've tried removing the flags altogether and 
just specifying the hight and width but it still fails.  I know the icons 
are there because i've used microangelo and other resource hackers to 
examine them. WinXP Home and Pro and 2k3 all have 238 icon objects and the 
Id's 132 & 163 are perfectly valid.  I don't understand how to use the api 
if i do specify LR_DEFAULTSIZE but want to load a specific size icon i.e. if 
i want to display the x16 or x48 icon.


"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:44f7214f$1@newsgroups.borland.com...
>
> "Mike Collins" <its@TheBottomOfThePost.com> wrote in message
> news:44f6ea84$1@newsgroups.borland.com...
>
>> Image->Picture->Icon->Handle = LoadImage(hDLL,
>> MAKEINTRESOURCE(12), IMAGE_ICON, 32, 32,
>> LR_DEFAULTSIZE);
>
> You must specify 0 for the cxDesired and cyDesired parameters if you use 
> the
> LR_DEFAULTSIZE flag.  This allows the OS to decide which dimensions to 
> load
> from the image based on the current display settings.
>
>> is it necessary to free the handle that is returned from
>> LoadImage using DestroyIcon?
>
> Yes, but you do not have to do it yourself.  TIcon takes ownership of the
> HICON and will free it for you when the TIcon itself is freed, or if you
> assign a new HICON to it.
>
>> i'm having a problem using LoadImage to load icons from shell32.dll.  To
>> avoid any possible copyright issues, i'm loading some Windows icons
> directly
>> from \\system32\\shell32.dll, using exactly the same code as above.
> However,
>> LoadImage seems to fail if i try to load an icon that has an Id grater
> than 56.
>
> Without actually seeing the icons for your copy of shell32.dll, my guess
> would be that the icons at those higher IDs don't have 32x32 versions
> available for them.  You have hard-coded the cxDesired and cyDesired
> parameters to always load 32x32 images only.
>
> Which exact IDs are you trying to load?  For example, in my copy of
> shell32.dll on Win98, there are no icon groups available between IDs 
> 47-132.
>
>
> Gambit
>
> 

"Mike Collins" <its@TheBottomOfThePost.com> wrote in message
news:44f7640a@newsgroups.borland.com...

> Still can't get it to work.  I've tried removing the flags altogether
> and just specifying the hight and width but it still fails.

Does it still report that th icon can't be found?  If so, then you are still
likely specifying the wrong ID to begin with.  Or it might be that you are
trying to retreive an icon that does not have a version available for the
current display resolution.

> I know the icons are there because i've used microangelo and other
> resource hackers to examine them. WinXP Home and Pro and 2k3
> all have 238 icon objects and the Id's 132 & 163 are perfectly valid.

> I don't understand how to use the api if i do specify LR_DEFAULTSIZE

As I mentioned earlier, if you use that flag, then you have to set the sizes
to 0 so that the OS can pick them.

> but want to load a specific size icon i.e. if i want to display the x16 or
x48 icon.

If you want to load a specific-sized icon then DO NOT specify the
LR_DEFAULTSIZE flag.


Gambit

Problem solved...

We were both kind of right - as you said, the id must be incorrect.  As it 
turns out, Microangelo was reporting an incorrect id - i used Resource 
Hacker and eXeScope and found a completly different ID - which works now.

However what is wired is that the incorrect ID, 132, kind of worked with 
ExtractIcon.  If i dropped the id by one, i.e. 131 it loaded the correct 
icon.  Very strange..

Thanks again,

Mike C

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:44f7707d$1@newsgroups.borland.com...
>
> "Mike Collins" <its@TheBottomOfThePost.com> wrote in message
> news:44f7640a@newsgroups.borland.com...
>