Feature request

[SinoTech]

I often have multiple projects within a workspace, and often got the problem that one project is working and another is not because of a fault in my project settings (a missing library or something like that). On Visual C++ you can open the settings for one project and then just select another project without re-opening the settings-dialog (when selecting another project the dialog just updates the shown values to those of the newly selected project). On codeblocks you have to open the dialog for one project, check the settings, close it and then open the same dialog for the other project.
So I would really appreciate if one could change that so that it works the same way as in Visual C++. I think this would really improve the usablillity when working with multiple projects.
And thank you for the great work, codeblocks is really a great IDE:

Cheers,

Sino

[Zini]

Unless I am missing something you can't access/active other projects while a project settings window (like Build options/properties) is open, because this window is modal. Obviously this would need to be removed first, if any improvements in this area are to be made. That would be a good move IMHO because the number of model dialogues in Code::Blocks is uncomfortably high (I consider any number >0 uncomfortably high).

I don't really like the behaviour you suggest. One obvious problem is the question what happens with changes to project settings not yet confirmed by clicking on the Okay button. Either you accept that these changes are lost when changing the project (clearly wrong) or you will need to insert a warning dialogue (very annoying) or you have some hidden changes, that get accepted as a side-effect by clicking Okay in the properties window for a different project (probably annoying too).

The Right Thing IMHO would be to have one non-model dialogue window per project. This way you could easily place two windows side by side and compare the properties of the two projects, which should make finding errors a lot easier.

[SinoTech]

[...]
I don't really like the behaviour you suggest. One obvious problem is the question what happens with changes to project settings not yet confirmed by clicking on the Okay button. Either you accept that these changes are lost when changing the project (clearly wrong) or you will need to insert a warning dialogue (very annoying) or you have some hidden changes, that get accepted as a side-effect by clicking Okay in the properties window for a different project (probably annoying too).
[...]

When select a different project, a notification is send to the settings dialog. If the settings have changed not yet commited, the settings dialog would show a dialog asking whether to apply changes or not. After that the settings dialog loads the settings for the newly shown project and displays them. So that doesn't seem to be real problem to me.

[...]
The Right Thing IMHO would be to have one non-model dialogue window per project. This way you could easily place two windows side by side and compare the properties of the two projects, which should make finding errors a lot easier.

Yes, that would be another way. It's only the current approach that bothers me when comparing settings between different projects (or when I need to change something on several projects).

Cheers,

Sino

[MortenMacFly]

this would really improve the usablillity when working with multiple projects.

Typical issue with VC users: C::B has another powerful concept: What you call "projects" in C::B can also be "targets" within a project. If you setup your project like this you'll have all settings into one dialog. Check the C::B project file as a tech-demo.

[SinoTech]

this would really improve the usablillity when working with multiple projects.

Typical issue with VC users: C::B has another powerful concept: What you call "projects" in C::B can also be "targets" within a project. If you setup your project like this you'll have all settings into one dialog. Check the C::B project file as a tech-demo.

Yes, you're right "targets" seem to be very useful and provide the functionality I want. However, in some cases it is a better approach to have multiple projects and in that case "targets" are not enough. Also I just recognized that when you open the "build options" dialog for a project, the left side of not only displays the available targets but also the project itself. So instead of just displaying the current project this list could contain all projects in the current workspace? Just as an idea :-)

Cheers,

Sino