Icon loadFromFile

Hi,

When an Icon that is loaded from a file adds itself to the image lists, it
scales the first image rather than using (or looking for) the correctly
sized image in the icon group.

This isnt a bug, but with the new look and feel spanning 3 icon sizes, it
shows more in D5 than D4.

I am not sure why icons loaded from an ExternalResource with loadIcon do
scale correctly, the only hint I could find in MSDN was from the copyImage
function:

| ...
| LR_COPYFROMRESOURCE Tries to reload an icon or cursor resource
| from the original resource file rather than simply copying the current
| image.
| ...
| This will succeed only if hImage was loaded by LoadIcon or LoadCursor,
| or by LoadImage with the LR_SHARED flag.

If I make the changes appended to the message, my icons loaded from files do
make use of the alternate images rather than scaling the first. For this to
work, icons loaded from files need to have a nil instanceHandle.

(The Image>>instanceHandle: comment suggests that instanceHandle can be nil,
but Image class>> fromFile: defaults to using SessionManager current
defaultResourceLibrary.)

Is this necessary? I am doing something wrong to need this?

Thanks
Steve

=======================


!Icon methodsFor!

addToImageList: aWinImageList mask: aColorOrNil
 "Private - Add a pictorial representation of the receiver to the
<WinImageList>
 argument, using the <Color> argument as the mask colour (although in this
 case the specified mask colour is ignored in favour of that of the icon)."

 ^instanceHandle isNil
  ifTrue: [aWinImageList addFileLoadedIcon: self]
  ifFalse: [aWinImageList addIcon: self]! !
!Icon categoriesFor: #addToImageList:mask:!double dispatch!private! !

!WinImageList methodsFor!

addFileLoadedIcon: anIcon
 "Add the Icon that was loaded using Icon>>loadFromFile.
 If anIcon's extent is different to the receivers, load the icon again with
the receivers extent.
 From MSDN LoadImage Function information:
  When you are finished using the bitmap, cursor, or icon, you can release
  its associated memory by calling one of the functions in the following
table. "


 | hIcon index |
 anIcon extent = self extent ifTrue: [^self addIcon: anIcon].
 hIcon := UserLibrary default
    loadImage: 0
    lpszName: anIcon fileSpec asParameter
    uType: IMAGE_ICON
    cxDesired: self extent x
    cyDesired: self extent y
    fuLoad: ##(LR_LOADFROMFILE | LR_COLOR).
 "If the function fails, fall back to adding the original icon"
 ^hIcon isNil
  ifTrue: [self addIcon: anIcon]
  ifFalse:
   [index := self addIcon: hIcon.
   UserLibrary default destroyIcon: hIcon.
   index]! !
!WinImageList categoriesFor: #addFileLoadedIcon:!adding!public! !


=======================

"Steve Waring" <[hidden email]> wrote in message
news:[hidden email]... do
> make use of the alternate images rather than scaling the first. For this
to
> work, icons loaded from files need to have a nil instanceHandle.
>
> (The Image>>instanceHandle: comment suggests that instanceHandle can be
nil,
> but Image class>> fromFile: defaults to using SessionManager current
> defaultResourceLibrary.)
>
> Is this necessary? I am doing something wrong to need this?

There is an issue of icons loaded from files not having the same useful
behaviour of adding the correct (or nearest) size image to an image list as
they do when loaded from a resource DLL, but just scaling the 32x32 icon.
Realistically it will have to be looked at after the 5.0 release. Your
modifications seem a reasonable idea, the alternative being to bind one's
icons into a resource DLL.

Regards

Blair