wxWidgets 2.6.4 Screws Up File-Type Icons!

[Biplab]

Hi All,

I've been using wxWidgets-2.6.4 to compile Code::Blocks since it was released. Recently I've noticed that it basically screws up the File-Type Icons due to some unknown reasons. I'm posting couple of screenshots which will make the problem clear to you.


This screenshot is from Rev 3658 (Official Release)



C::B + wxWidgets-2.6.4

Please look at the icons of C++, C and header files carefully.


C::B + wxWidgets-2.6.4

I'm not sure why it is happening. But it seems that this is a bug in wxWidgets-2.6.4.

Any suggestions on what is going wrong here??

Regards,

Biplab

[stahta01]

I have NO idea how wxWidgets could cause your problem. But, I am far from being an expert on it. I would guess this is a MS windows issues. Have you tried it with TortiseSVN turned off? I am compiling SVN against 2.6 Branch right now and see if I see it. I did NOT see the issue with 2.8.3.

Tim S

[Biplab]

I have NO idea how wxWidgets could cause your problem. But, I am far from being an expert on it. I would guess this is a windows issues.

Thanks Tim for your reply. This issue is in two PCs with Win XP. So I'm also puzzled.

I'm not sure whether wxWidgets is causing the problem or not, but two different PCs having same problem made me think so.

Anyway, I'm waiting for your response.

Regards,

Biplab

[thomas]

Hmm... I'm just working on the file and icon association code. Luckily I did not commit any of that, so you can't blame me 

Good job actually... if it fails, I'll blame wxWidgets

[Biplab]

Hmm... I'm just working on the file and icon association code. Luckily I did not commit any of that, so you can't blame me 

Good job actually... if it fails, I'll blame wxWidgets

When two different PCs were showing same problem, I was trying to ask others whether it's related to wxWidgets or not.

As far as I'm concerned, I've not made a mess (after fixing any bug) with that portion of code, too.

Ok, I'll recompile C::B with wx-2.6.3 and see if it persists or not.

Regards,

Biplab

[stahta01]

What SVN version of CB? And, did you get 2.6.4 from CVS or Download?
I did NOT see the issue with CB SVN 3761 and a CVS 2.6 Branch DLL (Not sure how old.)

Tim S

[Charon]

if you still have the problem with 2.6.3, you should regenerate windows' icon cache.
sometimes windows messes up its icon-cache when several things happen.

only way i know so far to regenerate it is through the use of "TweakUI". it has a button somewhere to regenerate the cache.

good luck
Markus

[Biplab]

I'm using Rev 3761 of C::B and wx-2.6.4 is downloaded from ftp (ftp://biolpc.., I forgot the exact link) just before it was released.

I recompiled C::B with wx-2.6.3. And the problem is gone.





Strange.. :?

Regards,

Biplab

[thomas]

Well, the association setting depends on the wxRegKey class (to do the actual work) and on wxGetOsVersion (to decide whether to use "local machine" or "user" namespace, Windows 98 vs. 2000/NT/XP).

Considering that 2.6.3 was released a year ago, there are quite a few candidate modifications in that time span

http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/src/msw/registry.cpp

Some of them deal with "constructing wxRegKey from string names", maybe something is messed up there.

[mandrav]

Well, blame it on the retarded windows way to set the associated icon.
As you know, icons embedded inside an exe are indexed by number. My guess would be that wx2.6.4 probably includes more built-in icons in its resource file so we bring more icons inside our exe. This, in turn, screws up the icon indexes for our associations. This is just a guess but I wouldn't call it "wild" .

[Biplab]

I think I've figured out the issue.

As you know, icons embedded inside an exe are indexed by number. My guess would be that wx2.6.4 probably includes more built-in icons in its resource file so we bring more icons inside our exe. This, in turn, screws up the icon indexes for our associations. This is just a guess but I wouldn't call it "wild" .

Yiannis is correct. Resource Hacker points that at id 1, standard wxWidgets Icon gets embedded, which basically screws up the rest of the icons. So all the numbers pointing to file type icons needs to be incremented by 1 to fix this issue.

Regards,

Biplab

[Biplab]

Following patch should fix this issue.

Code Select Expand

--- C:/wxWidgets-2.6.4/include/wx/msw/wx.rc Mon Mar 26 18:15:59 2007
+++ C:/wxWidgets-2.6.4/include/wx/msw/wx.rc Mon Mar 26 18:17:13 2007
@@ -79,7 +79,7 @@

// Low alphabetically to make it the default, but not so low as to
// affect applications that use 'a'
-bICON                           ICON "wx/msw/std.ico"
+//bICON                           ICON "wx/msw/std.ico"

//////////////////////////////////////////////////////////////////////////////
//

Though I've not tested the patch, but I'm quite sure that this is the source of problem.

I'll post the result after another full recompilation with wxWidgets-2.6.4.

Regards,

Biplab

[thomas]

My guess would be that wx2.6.4 probably includes more built-in icons in its resource file so we bring more icons inside our exe.

Hah! How easy

Well, people were asking for "skinnable" icons anyway, so I guess we could as well move the icons into a separate file, to avoid this problem in the future alltogether.

(Though I have no idea what file Windows wants then... .icl probably?)

[Biplab]

FYI, that line is not present in CVS HEAD snapshot, wx-2.8.3. Only wx 2.6.4 has this issue.

[Biplab]

Hi,

The patch I posted earlier fixes this issue. I've recompiled C::B with patched wxWidgets-2.6.4 and the issue gets resolved.

That line has been removed in later release, but unfortunately WX_26 series didn't get that update.

Regards,

Biplab