Dear all,
I'm using revision 2044 under Windows (unicode) as of now. I'm not an administrator on my machine which might be related to the following problems:
1.) If I click in the settings dialog of C::B on the button "Manage..." file association C::B crashes immediately without even producing a crash report.
2.) If I run C::B as administrator (using the "Run as.." menu of the explorer) I receive an error: "XRC resource 'askAssoc' (class 'wxDialog') not found!". If I click on OK then C::B is frozen and can only be killed by the task manager.
Anyone else experiencing the same?
With regards, Morten.
Edit 2: Removed "Edit 1" because of mistake.
confirmed
It seems like Thomas forgot to add the dialog's XRC :P
Quote from: mandrav on February 20, 2006, 09:50:36 AM
It seems like Thomas forgot to add the dialog's XRC :P
Alright! ...that would be the explanation why I cannot find any resource named "askAssoc"... ;-)
Quote from: mandrav on February 20, 2006, 09:50:36 AM
It seems like Thomas forgot to add the dialog's XRC :P
Not quite.... :)
It was there until you accidentially deleted it in revision 2043 :lol:
No worries, I'll re-add it.
2045 should work again.
Quote from: thomas on February 20, 2006, 11:42:47 AM
Quote from: mandrav on February 20, 2006, 09:50:36 AM
It seems like Thomas forgot to add the dialog's XRC :P
Not quite.... :)
It was there until you accidentially deleted it in revision 2043 :lol:
No worries, I'll re-add it.
Hmm, it seems we 've just found a bug (?) in wxSmith.
You see, I edited env_settings.xrc using wxSmith but it seems that it doesn't support more than one top-level window (i.e. a second dialog defined in the same XRC).
Still, why didn't you just add a new XRC file? ;)
Well, I thought it belongs to environment.
If you like, we can always separate it - luckily with XRC you don't have the same hassles as with adding new sources (breaking Linux compile).
Moved it to its own XRC (manage_assocs.xrc).
Quote from: mandrav on February 20, 2006, 12:06:47 PM
Moved it to its own XRC (manage_assocs.xrc).
I can confirm that 2048 is working properly. This applies for being an Admin as well as for being a Non-Admin (User) on a Windows machine (thus different registry sections are used). The new dialog is a great enhancement for setting up the associations in addition. I noticed the "Fortran sources" as new file type as well. Good work though, well done!
Morten.
There is one thing to note about that dialog. If you compile a development version, it will show everything unassigned, even if types *are* indeed assigned (to the other version). Also, if you enable automatic assoc checking with two different copies of Code::Blocks, they will be fighting over the associations on every application start (this has always been the case).
That "problem" arises because the application does not only check whether or not a type is generally assigned, but also whether it is assigned with itself.
I was uncertain for quite a while whether this should be "fixed", and whether this is actually a bug or a misfeature. Finally, I settled it as "correct behaviour". Not only because it is a lot less work :lol: but also because it is really correct. You normally don't have two different versions of Code::Blocks running on the same machine, and if you install a new version, you're normally interested mainly in that one, and having your files open in the wrong version although everything looks OK in the config dialog is a big turn-off.
If you really do have two versions regularly, you are either a developer (so you know about the issue) or you are doing something wrong.
... or you like living on the 'cutting' edge, you use the stable version (in this case RC2 ;-) ), and you want to try out 'the latest and greatest' nightly build version.
I will post this issue (side effect) on the nightly build forum. I agree with you Thomas, no need to change the code for this issue.