looks less perfect than in i-conized
in windows xp sp3 (no smoothing, pixels are visible)
Recently I had a small talk with Eugene Agafonov. He things maybe icons are different because GDI+ (not GDI) is used in his nice plugin i-conized.
Which icons are you referring to? VirtuaWin's Window List? On my machine the icons in the Window list are pixel for pixel identical to i-conized.
Hi, i'm referring to icons of folder (Explorer icon) In i-conized it looks nice but when i click on virtuawin i see pixels in this icon borders (like it was streched to 16x16 by removing each second row and second column).
Can you please attached a screen shot - I'm still not sure what you are referring to.
tomorrow in the morning i'll attach screen
here is it
Thanks for uploading the screenshot, I can now see the issue! Please have a look at what I see on my 32bit XP box - as you can see, the I-conize window (cyan colour) has exactly the same icon as VirtuaWin.
I don't think this issue is caused by the API used to render the icons, this is for two reasons:
1. Looking through the I-conize code I believe both programs use the same DrawIconEx function.
2. The icons in your screen shot are clearly different, the bottom edge of the folder is horizontal in the I-conize icon but rises in the VW one - two different icons.
I believe the issue is caused by a difference in the algorithms used to extract an icon for the program. Both programs first try using GetClassLong(whdl, GCL_HICON) to get an icon and I think this works for both on my XP box which is why both draw the same icon for me. But for some reason this fails on your machine for either just I-conize or both I-conize and VW, at which point I-conize locates the exe and loads an icon from the program whereas VirtuaWin uses the ICON_SMALL/ICON_BIG window messages to get an icon. Both approaches are valid, both give reasonable results and both could get a better icon (subjective and for another program VirtuaWin's could be better).
Thinking about why this issue is seen on your machine and not on mine and also why this issue occurs considering both programs use the same call to GetClassLong(whdl, GCL_HICON) to get an icon, the only thought I have is that iconize caches the icon, VirtuaWin doesn't and given you probably run VW & i-conize at login I think the initial call by iconize fails (for some reason, e.g. too early in explorer's initialization... not sure why) but VirtuaWin's later call succeeds and both succeed on my machine because I started virtuawin manually. It would be interesting to know if restarting iconize on your machine results in iconize using the same icon as VirtuaWin - does it?
Anyway the conclusion of this is that this is not a bug, both programs use the same drawing function, both programs use the same main method of getting an icon and both use legitimate backup methods. If my guess of the cause of the difference is correct then changing VirtuaWin's method is pointless because its call to GetClassLong succeeds. I would be very reluctant to change VirtuaWin's implementation because it has had years of testing and the algorithm used by i-conize to extract the exe is not supported on Win9x platforms.
Sorry for the long response....
Take look on function main_window::GetWindowIcon (http://iconized.git.sourceforge.net/git/gitweb.cgi?p=iconized/iconized;a=blob;f=iconizedDlg.cpp;h=b4815befa3e45c3c8690b116cb3fd501c3bdaa12;hb=a9e1534d1563d29b8552a3830fb6e52ec306fe0d)
It gets icon from from window but as far as I remember that code was mostly borrowed from VirtuaWin ;-)
Main window is drawn using GDI+ (Alpha channel, smooth resize and other cool staff) I'm not sure if it useful for VirtuaWin while it uses self-drawn items on standard Win32 menu. Correct me if I'm wrong.
BTW, That was one of the reason why I've created iconized: manage 9 desktops using menu-style UI is horrable for me ;-)
> I-conize window (cyan colour) has exactly the same icon as VirtuaWin
It seems to me you are using very old version of iconized ;-)
Thanks for the pointers, I have now submitted a fix for this issue.
As a side note you may want to consider simplifying your code in i-conize by making use of ICON_SMALL2 . While this was only introduced in XP the current fall back of i-conize to extract the icon from the program relies on the function GetModuleFileNameEx which means only support for NT & 2000 is added and like ICON_SMALL the returned icon does not need destroying.
I guess the one weakness this introduces is if the window's process is hung so SendMessageTimeout would timeout. Anyway the new VW icon extraction code is below.
/* First try to get the current icon from the app as the app can dynamically change the icon.
* Try to get a small icon first but if that fails (but not with timeout) try to get a big
* icon as some apps only have big icons (e.g. Opera). If that fails and we're on XP+ get the
system icon for the window using ICON_SMALL2 */
hIcon = NULL ;
/* didn't time out */
if((dIcon != 0) ||
(SendMessageTimeout(win->handle,WM_GETICON,ICON_BIG,0L,SMTO_ABORTIFHUNG|SMTO_BLOCK,100,&dIcon) && (dIcon != 0)) ||
((osVersion >= OSVERSION_XP) && SendMessageTimeout(win->handle,WM_GETICON,ICON_SMALL2,0L,SMTO_ABORTIFHUNG|SMTO_BLOCK,100,&dIcon) && (dIcon != 0)))
hIcon = (HICON) dIcon ;
if(hIcon == NULL)
/* Failed to get an icon from the app itself, try to get the registered class icon */
hIcon = (HICON) GetClassLong(win->handle, GCL_HICON) ;
Code submitted back to CVS and will be in the next release (v4.4)
Thanks guys, you're the best
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.