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.
(http://img2.freeimagehosting.net/uploads/aab5c7c40c.png)
This screenshot is from Rev 3658 (Official Release)
(http://img2.freeimagehosting.net/uploads/033d8bed4a.png)
C::B + wxWidgets-2.6.4
Please look at the icons of C++, C and header files carefully.
(http://img2.freeimagehosting.net/uploads/b54849c11f.png)
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
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
Quote from: stahta01 on March 26, 2007, 09:41:43 AM
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
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 8)
Good job actually... if it fails, I'll blame wxWidgets :)
Quote from: thomas on March 26, 2007, 09:58:58 AM
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 8)
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
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
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
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.
(http://img2.freeimagehosting.net/uploads/2f6b60771b.png)
(http://img2.freeimagehosting.net/uploads/011239f610.png)
Strange.. :?
Regards,
Biplab
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.
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" ;).
I think I've figured out the issue.
Quote from: mandrav on March 26, 2007, 12:04:27 PM
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. :D
Regards,
Biplab
Following patch should fix this issue.
--- 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
Quote from: mandrav on March 26, 2007, 12:04:27 PMMy 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?)
FYI, that line is not present in CVS HEAD snapshot, wx-2.8.3. Only wx 2.6.4 has this issue. :)
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
Quote from: Biplab on March 26, 2007, 12:20:32 PM
Following patch should fix this issue.
--- 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
I know this should fix it, but it will have side-effects...
By not importing the wx resources, we "lose" some necessary icons (like the right-pointing arrow displayed when hovering over the editor's left margin).
The "proper" way (if such thing exists) would be to alter our indices in associations.cpp based on the wxwidgets version. I think...
Quote from: mandrav on March 26, 2007, 01:51:27 PM
I know this should fix it, but it will have side-effects...
By not importing the wx resources, we "lose" some necessary icons (like the right-pointing arrow displayed when hovering over the editor's left margin).
The "proper" way (if such thing exists) would be to alter our indices in associations.cpp based on the wxwidgets version. I think...
No, this would not have any side effects. :)
If you look at the CVS of wxWidgets, that line was introduced in one revision and later was deleted and replaced with older code.
I'm posting the diff between latest wx.rc and the file supplied with wx-2.6.4.
--- C:/wxWidgets-2.6.4/include/wx/msw/wx.rc Mon Mar 26 20:04:24 2007
+++ C:/wxMSW-2.9.0/include/wx/msw/wx.rc Sun Feb 11 12:54:58 2007
@@ -6,7 +6,7 @@
// Modified by:
// Created:
// Copyright: (c) Julian Smart
-// RCS-ID: $Id: wx.rc,v 1.43.2.3 2006/06/18 11:06:36 JS Exp $
+// RCS-ID: $Id: wx.rc,v 1.49 2006/11/18 16:46:59 VZ Exp $
// Licence: wxWindows Licence
/////////////////////////////////////////////////////////////////////////////
@@ -63,6 +63,10 @@
// Default Icons
//
+// First wx icon in alphabetical order, so it will be used by Explorer if the
+// application doesn't have any icons of its own
+wxICON_AAA ICON "wx/msw/std.ico"
+
//wxDEFAULT_FRAME ICON "wx/msw/std.ico"
//wxDEFAULT_MDIPARENTFRAME ICON "wx/msw/mdi.ico"
//wxDEFAULT_MDICHILDFRAME ICON "wx/msw/child.ico"
@@ -77,10 +81,6 @@
wxICON_SMALL_FLOPPY ICON "wx/msw/floppy.ico"
wxICON_SMALL_REMOVEABLE ICON "wx/msw/removble.ico"
-// Low alphabetically to make it the default, but not so low as to
-// affect applications that use 'a'
-bICON ICON "wx/msw/std.ico"
-
//////////////////////////////////////////////////////////////////////////////
//
// Bitmaps
@@ -100,12 +100,19 @@
#if !defined(wxUSE_NO_MANIFEST) || (wxUSE_NO_MANIFEST == 0)
#if !defined(WX_MSC_FULL_VER) || WX_MSC_FULL_VER < 140040130
+// see "about isolated applications" topic in MSDN
+#ifdef ISOLATION_AWARE_ENABLED
+#define wxMANIFEST_ID 2
+#else
+#define wxMANIFEST_ID 1
+#endif
+
#if defined(WX_CPU_AMD64)
-1 24 "wx/msw/amd64.manifest"
+wxMANIFEST_ID 24 "wx/msw/amd64.manifest"
#elif defined(WX_CPU_IA64)
-1 24 "wx/msw/ia64.manifest"
+wxMANIFEST_ID 24 "wx/msw/ia64.manifest"
#elif defined(WX_CPU_X86)
-1 24 "wx/msw/wx.manifest"
+wxMANIFEST_ID 24 "wx/msw/wx.manifest"
#endif
#endif // !defined(WX_MSC_FULL_VER) || WX_MSC_FULL_VER < 140040130I'm using it currently. If I see any missing icons, cursors, I'll post.
Regards,
Biplab
any new side effects seen ?
Might make a mightly with wx2.6.4, but once more a patched one because of this issue .
Jolly nice wx ......
Quote from: killerbot on March 27, 2007, 09:39:22 AM
any new side effects seen ?
No, Not yet.
IMHO, it should not create any side-effects. Only the standard wx icon inclusion is removed. Rest of the wx resources will be added. :)
They've already replaced that line in newer version of wx. But unfortunately, wx-2.6.4 got the buggy one. :(
Quote from: killerbot on March 27, 2007, 09:39:22 AM
Might make a mightly with wx2.6.4, but once more a patched one because of this issue .
Jolly nice wx ......
No, not necessary. The runtime dll will not be affected. Only during compilation of any exe file based on wx-2.6.4 (in this case
codeblocks.exe), that patch is necessary. :)
Regards,
Biplab