let me give some information.
1) "Link libraries" list on the "linker tab" :
- correct, this is a bit to annoying, I will change it into an annoying dialog, which you can tell to never pop-up again.
2) this siutation is a bit more complex.
Initially there were no dialogs when you switch your selection in the tree or when you switched compiler. But initially there were a whole lot of inconsistencies, some changes would only happen when you pressed the OK button, and could have been lost when you switched your selection in the tree or you switched compiler. Other changes got applied directly the moment you changed them, leaving you with no way to cancel out.
Through the introduction of these new dialogs you can now cancel out (with 2 exceptions : adding/deleting a compiler and the advanced options, but those are on the todo list), since all changes are kept in memory and applied on 'save' time. There are now 3 'save' times :
- pressing the OK button
- switching compiler
- changes you selection in the tree
The way the compileroptionsdialog WAS and STILL is implemented I only keeps track of the active selection (project or target or compiler), meaning when one of those switches, it's state will change and be updated with the new selection, so at that time we either need to drop the old (modified) state or save it.
Looking elsewhere we see tha M$ Developer Studio does the same thing : when you change settings in the 'Debug' configuration and then in the dialog you switch to the 'Rele\ase' configuration you also get asked to apply or not. Their dialog also seems to keep track of just 1 selection.
But maybe we can do better, but this will require a major change (note : I might do it ;-) ), since the state has to be enlarged and you need to keep track of everything.
When you have a project whith 2 targets (debug and release) this state is very little and easy to have an overview of for the user. But consider the CB project : it has 23 more or less independent targets -> big state, ahrd as a user to keep track of what was altered and what was not (idea : show an * after the name in the tree). But I can immagine that some users will complain when they have changed several targets and then realize they made a mistake in some of them. Now what do you do : in our case, well on the current target is the state, so only this one can be damaged or cancelled. But what if all 'savings' are postponed till the very end, then cancelling out will drop all your changes, and it is not hard to immagine you wouldn't like to start all over again.
So everything at the end could be a dangerous way of working. Yes, we are all developers and we (should) know what we are doing. But if all us really now that well what we are doing, somebody please explain to me all those buggy software out there in the real world. We all make mistakes you know. And a developers tool is used by the experienced users but also by novices, so don't expect everyone to know the things on an equal experienced level.
I think the way it is now, and also the way M$ does it is a nice compromise to start out with, we could make the dialog also annoying so you can turn it off (and always 'yes' as the answer) so the experienced users don't need to click it (hey they don't need the cancel button anyway, why ? well they know what they are doing ;-) ). The one thing that M$ has and we don't have : "Apply" button, next to OK and Cancel, which can be pressed the moment you have changed something.
This is also on the TO-DO list, but I need to investigate a bit further, since the buttons are in a place where I think they might show up on other settings dialogs to (not sure).
Well, I'll put it on my TO-DO list to turn the current ones into "annoying" dialogs.
Note : some more of those dialogs will pop-up (annoying ones also). Because when you change the compiler of the project and you do NOT then allow it to change all the targets to that compiler also, the policies have to be checked and adjusted accordingly (you can not mix settings of 2 compilers), the same goes when you change the compiler of a target (don't mix with settings from the project).
And when you switch the compiler of a project/target all of it's current settings should be omitted, because settings of compiler A are probably different from the ones from compiler B (we already had a discussion about this, so please do not fire it up again ;-) ).
Anyway, I'll keep on thinking about the idea of doing all savings at the very end, and allowing to apply (apply button) for the current selection through a new button, amd showing the modified state (through a *) in the tree. Then at least if you think you made a mistake you can go and apply the ones you know you don't need to check again. But as I see it know this is an optimisation, first things should work correctly (eg : compiler switch -> policy adjustment), so it's at the bottom of the TODO list.
