Menu Icons are gone

[killerbot]

I have noticed that on one machine I seem to have lost the icons in the build menu, on my laptop they are still there.
Anyone else suffering from this, or even better, who has a solution.
Probably will have to delete something in default.conf (no, don't want to delete the conf all together) ??

Thanks,
Lieven

[thomas]

Hmmm... I doubt that doing anything with the config will fix the problem. The icons are (if I remember correctly) defined in XRC and not touched afterwards.

But before you delete anything, try renaming the config file. That way, you see if it is config-related, and you can go back in one second

[killerbot]

Tried out your suggestion, nope they didn't come back.
The reason I thought it might have something to do with the conf file is, sometimes the debugger toolbar is gone, and youcan get that one back by removing <LAYOUT> crc ... from the conf file.

Just noticed something else, since CB wanted to create a new default conf, it also asked if it may b the default app for c++ files, etc ...,
well I clicke on "yes" --> failed to create the keys in the registry.
Why : I formatted my c-drive an reinstalled XP a few days ago, there's 1 admin account and all other accounts I have made restricted  (so the account I work in is restricted), so it was not allowed to change the registry.
It is important to keep that in mind (there are cooperations where the users all are restricted !!) !!

Just wondered, where does CB wants to write that info, in the (current) user part of the registry (seems like a setting per user, since other users migh want to stick to dev-cpp ;-)  ).
In the per-user part of the registry , the user is allowed to write !! -> seems like CB does not write it there ?

I remember in some other post that several people were having problems also with CB and the regisrty (double cliking a cbp fil, gave an error message, though it did load it, etc ...), so maybe someone should take a closer look on the registry usage.

kind regards,
Lieven

[thomas]

Code::Blocks stores its stuff in HKEY_CLASSES_ROOT. Unluckily, I don't know enough about this Windows crap to tell whether you can write file associations to HKEY_CURRENT_USER somehow. From a logical point of view that should be possible, but when has anything in Windows ever been logical, consistent, or understandable...

I would not know where to put the file type in the user section. In the root section, it is just a key with the name of the filetype's extension added to the root node, but there seems to be no place in the user section (or it is well hidden?).

[takeshimiya]

In Microsoft Windows NT 4.0, all entries specific to file type associations are stored in the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes (HKEY_CLASSES_ROOT is an alias of location)

In Windows 2000 and Windows Server 2003, a new location is added for storage of user-specific file type associations in the following registry key:
HKEY_CURRENT_USER\SOFTWARE\Classes

[thomas]

So that means we would have to use different locations for different Windows versions? Great...
What about Win98 -- same as NT4, I assume?

[takeshimiya]

I suppose. It's almost the same case to where default.conf is saved (It differs from XP to 98, or 2000, even it's different from 98 to 98SE......).

Anyways, very few programs store associations in HKCU... Even in most MSDN articles seems to not talk about it.
I found about HKEY_CURRENT_USER\SOFTWARE\Classes in an article at MS support, not MSDN.

Thanks, Microsoft. :roll:

[killerbot]

so it should become "HKEY_CURRENT_USER" and check on the windows versions, for the older ones, at the top level.
Win9x did not real have user concepts.
Nice software (as CB) should not hijack the entire system, user x wants cb for C++ files, where user Y wants dev-cpp, and user z wants MS (well give that person linux for x-mass).
And as I found out, it is needed for restricted user accounts (safety safety).


How do these things happen on linux ??

Lieven

[killerbot]

I will try to create a patch for it, I hope I do it well, so all info , just bring it on.
Gonna start by searching how we get to know the windows version in wx ...
[edit] : wxGetOsVersion()
Lieven

[killerbot]

Maybe we can simplify the problem, just check if "HKEY_CURRENT_USER\SOFTWARE\Classes" exists, if it does -> write it their, if not use "HKEY_CLASSES_ROOT".
Anyone with win 95/98/Me/NT ? Can you check if the "HKEY_CURRENT_USER\SOFTWARE\Classes" exist ?

[takeshimiya]

Win9x did not real have user concepts.

Wrong, Windows 95 and Windows 98 doesn't had user concepts. Windows 98 SE, Windows ME does have user concepts.

Ie. %APPDATA% is:

Windows 95/98/98SE/Me
C:\Windows\Application Data\

Windows 98SE/Me with user management enabled
C:\Windows\Profiles\<Windows user name>\Application Data\

Windows NT4
C:\Winnt\Profiles\<Windows user name>\Application Data\

Windows 2000/XP
C:\Documents and Settings\<Windows user name>\Application Data\

I don't know what's the situation in the registry, but for sure it's somewhat different to complicate the things...

[killerbot]

I created a patch for it, works on my XP machine.
https://sourceforge.net/tracker/index.php?func=detail&aid=1393650&group_id=126998&atid=707418

Note : the old problem of clicking on a project, workspace given the error (though opening correctly) is not gone yet, will try to take a look at that also someday.

Lieven

[killerbot]

A little bit of reading at the link :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fa_verbs.asp

3 ways for those verbs : command (cb does that), DDE, cb does that also, and another one.
Why do we need that DDE. Because if the DDE failt, it falls back to the command one (unless you specify some other fallback). I get the impression if you double click for example on a cbp file, the DDE fails (the message box we see) and then switches back to the command version, which eventually opens the cbp file ok.

Who added that DDE : why ? Can we do without it ?

EDIT : I did the following test : for the cbp file renamed the ddeexec key, double click on a cbp file -> no error message at all. --> Die DDE, die, die  ;-)


Cheers,
Lieven

PS : I am not that familiar with all these registry things and verbs yet, so if I overlook something, please point it out to me, so at least I learn something.

[Michael]

Hello,

I have had some problems with icons too in my notebook, but this time with the debug icons in the toolbar (the ones for fast access). If I pressed with the right button of the mouse I could just add/remove the icons for the main and the compiler, but not for the debugger (there was not even the option :?). Anyway, after I tried in another computer C::B worked fine. I assume it was some local problem. I have had such problem with RC2 and several SVN binary snapshots.

Michael

[tiwag]

back to topic "Menu Icons are gone"

just noticed, that the actual SVN Windows build lacks the most of the menu icons compared to the linux version

see the screenshots


[attachment deleted by admin]