Forum

I’ve got an application with >10 dockable control bars, and am saving their state with ProfileBarStateSave() and ProfileBarStateLoad(). My problem is that these two functions seem to serialise out the states to the registry in a fixed order, so if I remove a bar then all of the bars whose state has been saved after the removed bar get the wrong state loaded.

Is there a way to get the loading code to use the bar’s ID to assign state to the new bars? At present, all I can do is recreate the default state whenever I add or remove control bars, which is annoying my users.

OK, thanks, I shall look forward to the fixed version.

At the moment, the number of saved control bars (the CExtControlBar windows) must be equal to the number of control bars created in your application. Each created control bar is supplied with the information about where it should be docked and etc. If you modified your application and, for example, removed some control bar, then when the library reads the data about this control bar from the registry and it cannot find the real control bar, a collision occurs. Things get worse when this control bar was docked with some other bars and they depend on each other.

We plan to resolve this issue in two ways:
1) using XML serialization;
2) improving the algorithm for restoring the state of saved control bars;

Right now we can offer you a solution that is based on dynamic control bars (CExtDynamicControlBar windows controlled by the CExtDynamicBarSite object). It is demonstrated in the SDI_DynamicBars and MDI_DynamicBars applications. You can create any number of dynamic control bars, create new ones or destroy existing control bars at runtime and save their states: the above mentioned collision is impossible