f



How do icons work?

Hello,
  PMMail offers a method to customize some of its icons. Place an icon
file in a directory and it replaces the default icon.
  I do not understand how os/2 and the PM decide how to select an icon
image from an icon file with multiple size versions of an image.

  The code does this:
- loads the complete icon file into memory
- checks the type. Only BFT_BITMAPARRAY and BFT_COLORICON are interesting.
- scans the bitmap array data looking for an image size to match the
  system icon sizes, WinQuerySysValue(HWND_DESKTOP, SV_CXICON).
  The "mini" size is set to half the system size.
- GpiCreateBitmap() creates the icon mask and image
- WinCreatePointerIndirect() creates the actual icon

  Both regular and mini icon images are created for
WinCreatePointerIndirect(), 4 total.

  On my computer WinQuerySysValue() returns the system icon size as 40x40.
 The screen size is 1600x1200.
  What happens currently is that only the 40x40 (or 32x32 depending on
screen size) size icons are acknowledged; if there are 20x20 or 16x16
versions, those are ignored. WinCreatePointerIndirect() scales the larger
icon down in size to fit the mini-icon format, say 40x40 -> 20x20. That
result is not very appealing since the downsize method deletes every other
row and column to get the 20x20 size.
  If I force the use of a 20x20 icon, that image is first scaled up to
40x40 using some dithering to smooth the edges, then scaled down to 20x20,
an even less appealing result.

  Is there a better way to do this?
  How do I create an mini icon that correctly uses the mini icon images in
the icon file?
  Is there documentation that better describes icon manipulation than what
is in the PM Reference?

-- 
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
0
Jim
11/10/2009 6:44:19 PM
comp.os.os2.programmer.misc 1326 articles. 0 followers. Post Follow

21 Replies
281 Views

Similar Articles

[PageSpeed] 39

Jim Moe schrieb:
> Hello,
>   PMMail offers a method to customize some of its icons. Place an icon
> file in a directory and it replaces the default icon.
>   I do not understand how os/2 and the PM decide how to select an icon
> image from an icon file with multiple size versions of an image.
> 
>   The code does this:
> - loads the complete icon file into memory
> - checks the type. Only BFT_BITMAPARRAY and BFT_COLORICON are interesting.
> - scans the bitmap array data looking for an image size to match the
>   system icon sizes, WinQuerySysValue(HWND_DESKTOP, SV_CXICON).
>   The "mini" size is set to half the system size.
> - GpiCreateBitmap() creates the icon mask and image
> - WinCreatePointerIndirect() creates the actual icon
> 
>   Both regular and mini icon images are created for
> WinCreatePointerIndirect(), 4 total.
> 
>   On my computer WinQuerySysValue() returns the system icon size as 40x40.
>  The screen size is 1600x1200.
>   What happens currently is that only the 40x40 (or 32x32 depending on
> screen size) size icons are acknowledged; if there are 20x20 or 16x16
> versions, those are ignored. WinCreatePointerIndirect() scales the larger
> icon down in size to fit the mini-icon format, say 40x40 -> 20x20. That
> result is not very appealing since the downsize method deletes every other
> row and column to get the 20x20 size.
>   If I force the use of a 20x20 icon, that image is first scaled up to
> 40x40 using some dithering to smooth the edges, then scaled down to 20x20,
> an even less appealing result.

Did you make sure to pass handles to hbmMinPointer / hbmMiniColor 
instead of hbmPointer / hbmColor ?

That should prevent the up-/downscaling that you observe. Don't know 
what fPointer does. You should experiment with TRUE/FALSE setting.

Lars
0
Lars
11/10/2009 7:52:45 PM
On 11/10/09 12:52 pm, Lars Erdmann wrote:
> 
> Did you make sure to pass handles to hbmMinPointer / hbmMiniColor 
> instead of hbmPointer / hbmColor ?
> 
  Yes.
  Hmm. Originally hbmPointer and hbmMinPointer were set to the same
handle. Later I searched for appropriate images and set hbmPointer/Color
to the full size image and hbmMiniPointer/Color to the small size image.
  The results are identical.
  hbmPointer and hbmColor cannot be NULLHANDLE.

> That should prevent the up-/downscaling that you observe. Don't know 
> what fPointer does. You should experiment with TRUE/FALSE setting.
> 
  From the PM Reference:
"fPointer is set to TRUE if a pointer is being created, or to FALSE if an
icon is being created."
  I did try setting the flag to TRUE with even worse results.

-- 
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
0
Jim
11/11/2009 1:26:53 AM
On Tue, 10 Nov 2009 18:44:19 UTC, Jim Moe <jmm-list.AXSPAMGN@sohnen-moe.com> wrote:

>   How do I create an mini icon that correctly uses the mini icon images in
> the icon file?

I encountered this problem with RWS, trying to pass WPS mini-icons
to other apps.

WinCreatePointerIndirect() just won't create mini-icons - it ignores
ptrInfo.hbmMiniPointer & ptrInfo.hbmMiniColor.  If you put the mini
info in the full-sized fields, it will double each line to create a
misshapen full-sized icon.

However, the resizing process appears to be symmetrical:  when you
display one of these bloated icons as a mini, PM will remove every
other line, giving you an exact replica of the original.

If you have RWS installed, you can confirm this using Firefox.
Open a folder in details view, then view the same folder in FF.
Now, use a screen magnifying tool to compare the two.  The color
palette may be wrong in FF, but otherwise the two are identical.



-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==
___________________________________________________________________
                |
                |         DragText v3.9 with NLS support
Rich Walsh      |   A Distinctly Different Desktop Enhancement
Ft Myers, FL    |         http://e-vertise.com/dragtext/
___________________________________________________________________

0
Rich
11/11/2009 1:46:55 AM
On 11/10/09 06:46 pm, Rich Walsh wrote:
> 
>>   How do I create an mini icon that correctly uses the mini icon images in
>> the icon file?
> 
> WinCreatePointerIndirect() just won't create mini-icons - it ignores
> ptrInfo.hbmMiniPointer & ptrInfo.hbmMiniColor.  If you put the mini
> info in the full-sized fields, it will double each line to create a
> misshapen full-sized icon.
> 
  Yes, that is what I discovered as well.

> However, the resizing process appears to be symmetrical:  when you
> display one of these bloated icons as a mini, PM will remove every
> other line, giving you an exact replica of the original.
> 
  In this respect I got very lucky when creating the icons for PMMail.
When I made the full size versions, I doubled all of the line widths and
heights from the mini versions. As a result I did not know what was
actually happening until other people started complaining about how their
icons looked like crap.

-- 
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
0
Jim
11/11/2009 5:52:26 AM
Jim Moe wrote:
> On 11/10/09 06:46 pm, Rich Walsh wrote:
>>>   How do I create an mini icon that correctly uses the mini icon images in
>>> the icon file?
>> WinCreatePointerIndirect() just won't create mini-icons - it ignores
>> ptrInfo.hbmMiniPointer & ptrInfo.hbmMiniColor.  If you put the mini
>> info in the full-sized fields, it will double each line to create a
>> misshapen full-sized icon.
>>
>   Yes, that is what I discovered as well.
> 
>> However, the resizing process appears to be symmetrical:  when you
>> display one of these bloated icons as a mini, PM will remove every
>> other line, giving you an exact replica of the original.
>>
>   In this respect I got very lucky when creating the icons for PMMail.
> When I made the full size versions, I doubled all of the line widths and
> heights from the mini versions. As a result I did not know what was
> actually happening until other people started complaining about how their
> icons looked like crap.

Container views with mini icons seemed to work as I expected.  I create
the container with the CCS_MINIICONS class style and then put my mini
icon handle in the record's hptrIcon field instead of hptrMiniIcon.  No
apparent scaling going on, although maybe under the hood it is doing the
scale up, then scale down scenario.

-- 
Reverse the parts of the e-mail address to reply by mail.
0
Marty
11/11/2009 6:36:49 AM
On 11/10/09 11:36 pm, Marty wrote:
> 
> Container views with mini icons seemed to work as I expected.  I create
> the container with the CCS_MINIICONS class style and then put my mini
> icon handle in the record's hptrIcon field instead of hptrMiniIcon.  No
> apparent scaling going on, although maybe under the hood it is doing the
> scale up, then scale down scenario.
> 
  If it is scaling, you'd know it.
  That is what I am doing. Well, it looks like I am doing that, the code
says I am, it works for the default icons, but something is missing?
  The default icons are defined in a resource file are retrieved at
program startup with WinLoadPointer(). In absence of a custom icon file,
hptrIcon for the control is assigned that handle.

  How do you create the icon itself that is assigned to hptrIcon? Is it
created from an <.ico> file at runtime? Or from a resource file at compile
time?

-- 
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
0
Jim
11/11/2009 6:48:35 AM
On 10 nov, 22:46, "Rich Walsh" <spamyours...@127.0.0.1> wrote:
> On Tue, 10 Nov 2009 18:44:19 UTC, Jim Moe <jmm-list.AXSPA...@sohnen-moe.c=
om> wrote:
> > =A0 How do I create an mini icon that correctly uses the mini icon imag=
es in
> > the icon file?
>
> I encountered this problem with RWS, trying to pass WPS mini-icons
> to other apps.
>
> WinCreatePointerIndirect() just won't create mini-icons - it ignores
> ptrInfo.hbmMiniPointer & ptrInfo.hbmMiniColor. =A0If you put the mini
> info in the full-sized fields, it will double each line to create a
> misshapen full-sized icon.
>
> However, the resizing process appears to be symmetrical: =A0when you
> display one of these bloated icons as a mini, PM will remove every
> other line, giving you an exact replica of the original.
>
> If you have RWS installed, you can confirm this using Firefox.
> Open a folder in details view, then view the same folder in FF.
> Now, use a screen magnifying tool to compare the two. =A0The color
> palette may be wrong in FF, but otherwise the two are identical.
>
> --
> =3D=3D =3D=3D almost usable email address: =A0Rich AT E-vertise.Com =3D=
=3D =3D=3D
> ___________________________________________________________________
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 DragText v3.9 with NLS =
support
> Rich Walsh =A0 =A0 =A0| =A0 A Distinctly Different Desktop Enhancement
> Ft Myers, FL =A0 =A0| =A0 =A0 =A0 =A0http://e-vertise.com/dragtext/
> ___________________________________________________________________

Can you elaborate on this technique a bit further. I came across this
bug very recently and I just re-used some code where the icons where
treated as BITMAPS when it was required. Still, I would like to use
the scaling trick better. Can you post a snippet?

Thanks
0
lpino
11/11/2009 1:51:36 PM
On Wed, 11 Nov 2009 06:36:49 UTC, Marty <net@comcast.martyamodeo> wrote:

> Container views with mini icons seemed to work as I expected.  I create
> the container with the CCS_MINIICONS class style and then put my mini
> icon handle in the record's hptrIcon field instead of hptrMiniIcon.  No
> apparent scaling going on, although maybe under the hood it is doing the
> scale up, then scale down scenario.

If you specify a mini then give it a mini, PM has no reason to modify
it.  Apparently you used a regular RECORDCORE struct and got the
desired results by putting the "wrong" handle in the right field.
I've only used MINIRECORDCOREs where there's just one HPTR field,
so I didn't have to play that game.  What does PMMail use?


-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==
___________________________________________________________________
                |
                |         DragText v3.9 with NLS support
Rich Walsh      |   A Distinctly Different Desktop Enhancement
Ft Myers, FL    |         http://e-vertise.com/dragtext/
___________________________________________________________________

0
Rich
11/12/2009 4:51:56 AM
On Wed, 11 Nov 2009 13:51:36 UTC, lpino <lpino@previred.com> wrote:
> On 10 nov, 22:46, "Rich Walsh" <spamyours...@127.0.0.1> wrote:

> > However, the resizing process appears to be symmetrical: �when you
> > display one of these bloated icons as a mini, PM will remove every
> > other line, giving you an exact replica of the original.
> 
> Can you elaborate on this technique a bit further. I came across this
> bug very recently and I just re-used some code where the icons where
> treated as BITMAPS when it was required. Still, I would like to use
> the scaling trick better. Can you post a snippet?

As described, there's no technique or code to elaborate on.  The source
data was a mini icon's bitmap & mask.  When I duplicated it, the result
was an up-scaled full-size icon.  When I wanted to display it elsewhere,
I told PM I wanted a mini icon but gave it the full-sized version.  PM
down-scaled the icon for me, giving me an exact copy of the source,
which is what I wanted in the first place.

If you want to see some code that does this "manually", look at
> http://hg.mozilla.org/mozilla-central/file/ca31932ed41b/modules/libpr0n/decoders/icon/os2/nsIconChannel.cpp#l521

This converts the color bitmap of an OS/2 icon to a format usable
by Cairo.  Note this method's 'fShrink' argument.

For an earlier, pre-Cairo version of this, see
> http://hg.mozilla.org/mozilla-central/file/9b2a99adc05e/modules/libpr0n/decoders/icon/os2/nsIconChannel.cpp#l530

Here, there are separate methods for converting & shrinking the bitmap.

In either case, the process is the same:  skip every other line,
and on lines you keep, skip every other pixel.


-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==
___________________________________________________________________
                |
                |         DragText v3.9 with NLS support
Rich Walsh      |   A Distinctly Different Desktop Enhancement
Ft Myers, FL    |         http://e-vertise.com/dragtext/
___________________________________________________________________

0
Rich
11/12/2009 5:15:19 AM
On 11/10/09 06:46 pm, Rich Walsh wrote:
> 
> However, the resizing process appears to be symmetrical:  when you
> display one of these bloated icons as a mini, PM will remove every
> other line, giving you an exact replica of the original.
> 
  That is not my experience. :-( Hence this posting.
  If WinCreatePointerIndirect() is given mini icon images, it does not
scale them up by duplicating rows and columns. The method appears a bit
more advanced and involves shading or dithering or smoothing or etc. When
it then scales it down, the simpler method of removing every other pixel
is used. The result is undesirable.
  AFAICT WinCreatePointer() has the same shortcoming as
WinCreatePointerIndirect(), and is probably the basis for
WinCreatePointerIndirect().

  So my question is: How do I create mini icons?
  Is there really no API function that does so? The PM or WPS would seem
to indicate otherwise but I cannot find what to do.

-- 
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
0
Jim
11/12/2009 4:52:04 PM
Jim Moe wrote:
> On 11/10/09 11:36 pm, Marty wrote:
>> Container views with mini icons seemed to work as I expected.  I create
>> the container with the CCS_MINIICONS class style and then put my mini
>> icon handle in the record's hptrIcon field instead of hptrMiniIcon.  No
>> apparent scaling going on, although maybe under the hood it is doing the
>> scale up, then scale down scenario.
>>
>   If it is scaling, you'd know it.
>   That is what I am doing. Well, it looks like I am doing that, the code
> says I am, it works for the default icons, but something is missing?
>   The default icons are defined in a resource file are retrieved at
> program startup with WinLoadPointer(). In absence of a custom icon file,
> hptrIcon for the control is assigned that handle.
> 
>   How do you create the icon itself that is assigned to hptrIcon? Is it
> created from an <.ico> file at runtime? Or from a resource file at compile
> time?

In my case I compiled them into a DLL and loaded the resource.

-- 
Reverse the parts of the e-mail address to reply by mail.
0
Marty
11/12/2009 10:24:33 PM
On 11/12/09 03:24 pm, Marty wrote:
>> 
>>   How do you create the icon itself that is assigned to hptrIcon? Is it
>> created from an <.ico> file at runtime? Or from a resource file at compile
>> time?
> 
> In my case I compiled them into a DLL and loaded the resource.
> 
  WinLoadPointer() then. That would be similar to creating a resource file
(RC) and linking it at build time. That works also.
  So far, though, there does not seem to be a way to create a mini icon
from an icon file at runtime, at least no method that does not use the
full size icon and shrinks it.

-- 
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
0
Jim
11/12/2009 10:52:23 PM
On Thu, 12 Nov 2009 16:52:04 UTC, Jim Moe <jmm-list.AXSPAMGN@sohnen-moe.com> wrote:
> On 11/10/09 06:46 pm, Rich Walsh wrote:
> > 
> > However, the resizing process appears to be symmetrical:  when you
> > display one of these bloated icons as a mini, PM will remove every
> > other line, giving you an exact replica of the original.
> > 
>   That is not my experience. :-( Hence this posting.
>   If WinCreatePointerIndirect() is given mini icon images, it does not
> scale them up by duplicating rows and columns. The method appears a bit
> more advanced and involves shading or dithering or smoothing or etc. When
> it then scales it down, the simpler method of removing every other pixel
> is used. The result is undesirable.

If you're getting dithering or whatever, then you have another problem.
The most likely is a size mismatch, i.e. starting with a 16x16 or 32x32
icon on a system that requires a 20x20 or 40x40 icon.  This would definitely
cause PM to interpolate pixels.

To confirm (once again) that the 16x16 -> 32x32 -> 16x16 conversion
does not produce any corruption, I modified an RWS-based app, Iconomize,
to use small rather than full-sized icons.  I then compared the mini-icons
shown in WPS folders to those shown in the container control in Iconomize.
They were absolutely, pixel-for-pixel, identical.


-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==
___________________________________________________________________
                |
                |         DragText v3.9 with NLS support
Rich Walsh      |   A Distinctly Different Desktop Enhancement
Ft Myers, FL    |         http://e-vertise.com/dragtext/
___________________________________________________________________

0
Rich
11/13/2009 2:06:11 AM
On 11/12/09 07:06 pm, Rich Walsh wrote:
>>   If WinCreatePointerIndirect() is given mini icon images, it does not
>> scale them up by duplicating rows and columns. The method appears a bit
>> more advanced and involves shading or dithering or smoothing or etc. When
>> it then scales it down, the simpler method of removing every other pixel
>> is used. The result is undesirable.
> 
> If you're getting dithering or whatever, then you have another problem.
> The most likely is a size mismatch, i.e. starting with a 16x16 or 32x32
> icon on a system that requires a 20x20 or 40x40 icon.  This would definitely
> cause PM to interpolate pixels.
> 
  The icons files have all 4 sizes: 16, 20, 32, and 40. The two that match
the system icon size and 1/2 that size are chosen.
  Hmm. I have been assuming that WinCreatePointerIndirect() is the culprit
here. Maybe it is the Container Control itself; it does use a RECORDCORE
rather than MINI-.
  Although the docs for WinCreatePointer() do say for the fPointer flag:
"FALSE: The bit map should be stretched (if necessary) to the system icon
dimensions."
  The docs for WinCreatePointerIndirect() are silent on this aspect.
  It implies that only full size icons are considered. No mention of mini
icons.
  I wonder if it is possible to use WPS functions to convert the icon file
to an icon...

-- 
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
0
Jim
11/13/2009 7:57:30 AM
On Fri, 13 Nov 2009 02:06:11 UTC, "Rich Walsh" <spamyourself@127.0.0.1> wrote:

> > > However, the resizing process appears to be symmetrical:  when you
> > > display one of these bloated icons as a mini, PM will remove every
> > > other line, giving you an exact replica of the original.
> > > 
> >   That is not my experience. :-( Hence this posting.
> >   If WinCreatePointerIndirect() is given mini icon images, it does not
> > scale them up by duplicating rows and columns. The method appears a 
> > bit more advanced and involves shading or dithering or smoothing or 
> > etc. When it then scales it down, the simpler method of removing every 
> > other pixel is used. The result is undesirable.
> 
> If you're getting dithering or whatever, then you have another problem.

Rich, are you sure you don't have SET ENH_STRETCH=NO turned on?


-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/13/2009 10:28:01 AM
On Fri, 13 Nov 2009 10:28:01 UTC, "Alex Taylor" <mail.me@reply.to.address> wrote:

> Rich, are you sure you don't have SET ENH_STRETCH=NO turned on?

Ooops... I've had that in place for so long that I never thought about
it.  When I removed it & rebooted, I found Jim is right:  the result
of up-scaling then down-scaling does produce ugly mini icons.

Within one's own app like PMMail, it's possible to work around this
by adding SET ENH_STRETCH=NO to the end of the environment strings.
However, for RWS, I wouldn't consider messing with the WPS's
environment.  I guess I'll have to come up with a new way to pass
mini icons between processes...


-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==
___________________________________________________________________
                |
                |         DragText v3.9 with NLS support
Rich Walsh      |   A Distinctly Different Desktop Enhancement
Ft Myers, FL    |         http://e-vertise.com/dragtext/
___________________________________________________________________

0
Rich
11/14/2009 2:14:38 AM
On 11/13/09 07:14 pm, Rich Walsh wrote:
> 
>> Rich, are you sure you don't have SET ENH_STRETCH=NO turned on?
> 
> Ooops... I've had that in place for so long that I never thought about
> it.  When I removed it & rebooted, I found Jim is right:  the result
> of up-scaling then down-scaling does produce ugly mini icons.
> 
> Within one's own app like PMMail, it's possible to work around this
> by adding SET ENH_STRETCH=NO to the end of the environment strings.
> 
  Changing (or creating) the setting for ENH_STRETCH in the program in not
good enough. It must be set before the program is started. I also
discovered it did not matter what the setting was, YES or NO, as long as
ENH_STRETCH was defined.

-- 
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
0
Jim
11/14/2009 3:04:51 AM
On Sat, 14 Nov 2009 03:04:51 UTC, Jim Moe <jmm-list.AXSPAMGN@sohnen-moe.com> wrote:
> On 11/13/09 07:14 pm, Rich Walsh wrote:
> > 
> > Within one's own app like PMMail, it's possible to work around this
> > by adding SET ENH_STRETCH=NO to the end of the environment strings.
> > 
>   Changing (or creating) the setting for ENH_STRETCH in the program in not
> good enough. It must be set before the program is started. I also
> discovered it did not matter what the setting was, YES or NO, as long as
> ENH_STRETCH was defined.

There's nothing to stop you from messing with the environment strings
(and I don't mean the C RTL environment, I mean the real thing).  That's
what cmd.exe does when you use the SET command.  Of course, if you want
to access the f/q exename or the app's commandline args, you'd better
do so before adding any strings.  cmd.exe doesn't seem to care and just
overwrites them.  (To demonstrate this, look at cmd.exe's environment
segment in Theseus, then add some strings at the commandline and look
again.)

The only question is when PM looks in the environment for this string.
It seems unlikely that it would do so before it actually needs to.
If so, you could add the string any time before you create your first
icon.


-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==
___________________________________________________________________
                |
                |         DragText v3.9 with NLS support
Rich Walsh      |   A Distinctly Different Desktop Enhancement
Ft Myers, FL    |         http://e-vertise.com/dragtext/
___________________________________________________________________

0
Rich
11/14/2009 9:48:24 AM
On Sat, 14 Nov 2009 02:14:38 UTC, "Rich Walsh" <spamyourself@127.0.0.1> wrote:

> Within one's own app like PMMail, it's possible to work around this
> by adding SET ENH_STRETCH=NO to the end of the environment strings.
> However, for RWS, I wouldn't consider messing with the WPS's
> environment.  I guess I'll have to come up with a new way to pass
> mini icons between processes...

It's not really ideal in this case, as the setting will be inherited by
all child processes as well.  In an email program, this includes any 
time the user opens an attachment.

Since images are sent as email attachments fairly often, disabling
smooth scaling may have actual usability implications.

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
11/15/2009 1:56:01 AM
On Sun, 15 Nov 2009 01:56:01 UTC, "Alex Taylor" <mail.me@reply.to.address> wrote:
> On Sat, 14 Nov 2009 02:14:38 UTC, "Rich Walsh" <spamyourself@127.0.0.1> wrote:
> 
> > Within one's own app like PMMail, it's possible to work around this
> > by adding SET ENH_STRETCH=NO to the end of the environment strings.
> 
> It's not really ideal in this case, as the setting will be inherited by
> all child processes as well.  In an email program, this includes any 
> time the user opens an attachment.
> 
> Since images are sent as email attachments fairly often, disabling
> smooth scaling may have actual usability implications.

Whatever you do, you can undo:  add the string, create the icons,
then replace the first letter of the string will a nul.  No big deal.

I haven't tested this but that's what I'd try.  While I had the
string remmed-out in config.sys, I did confirm that PM uses the
app's environment, not some global version (e.g. pmshell #1's).
That's why I think it should work.

Another thought:  if you point WinLoadFileIcon() at a .ico file,
does it return that file's contents or the icon for .ico files?


-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==
___________________________________________________________________
                |
                |         DragText v3.9 with NLS support
Rich Walsh      |   A Distinctly Different Desktop Enhancement
Ft Myers, FL    |         http://e-vertise.com/dragtext/
___________________________________________________________________

0
Rich
11/15/2009 5:08:37 PM
On 11/15/09 10:08 am, Rich Walsh wrote:
> 
> Another thought:  if you point WinLoadFileIcon() at a .ico file,
> does it return that file's contents or the icon for .ico files?
> 
  If the source file has an icon resource built into it, that resource is
returned by the function. If there is no resource, a generic icon is
returned. In all cases, not the icon in the icon file.

-- 
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
0
Jim
11/15/2009 7:47:32 PM
Reply: