|
|
|
|
Forum
Please
Log In
to post a new message or reply to an existing one. If you are not registered, please
register.
NOTE: Some forums may be read-only if you are not currently subscribed to
our technical support services.
Subject |
Author |
Date |
|
Dmitri Zhukov
|
Mar 10, 2004 - 4:17 AM
|
I ’ve evaluting trial version and have a problem with CExtControlBar::ProfileBarStateLoad function.
The problem is that function throws an exception when it sees an entry in registry for window (given its ID) and the window with given ID is not created at this time. I have unknown at compile time number of CExtControlBars- all the docking windows are read from the configration TXT file. So I may encounter the sitaution when I have a saved bar state (from previous session) but no instance of CExtControlBar with given ID (user may altered the configurtion). How to handle it?
|
|
Sergiy Lavrynenko
|
Mar 10, 2004 - 10:22 AM
|
Hi Dmitri,
Yes, the code responsible for loading the saved states of control bars requires that all the dynamic control bars whose states have been previously saved should have been already created. Of course, you can destroy your dynamic bars before saving the frame window’s state, but this is not a good approach. The good solution to your task is described in the following steps:
- After saving all the control bar’s states by invoking
CExtControlBar::ProfileBarStateSave() (or CExtControlBar::ProfileBarStateSerialize() ), you should save somewhere the number of your dynamic bars, the dialog control identifier of each dynamic bar and possibly some custom information (e.g. which type of window is inserted to each bar, URL of the document, and etc.)
- Before loading the control bar’s states by invoking
CExtControlBar:: ProfileBarStateLoad() (or CExtControlBar::ProfileBarStateSerialize() ), you should read the number of your dynamic bars, their dialog control identifiers, and create all the control bars. Carefully performed, the state loading will cause no problems for you anymore.
You may need to hide your dynamic bars before saving their states or immediately after the state loading if some of them cannot be initialized during the application startup. The child windows of the dynamic bars may be created later when your application is provided with enough information for their initialization. Even Visual Studio .NET partially solves the dynamic dockable document problem. You can open several different MSDN-help pages and make them dockable (via the context menu on MDI-tab items), dock or float their dynamic bars to different locations, then close VS.NET IDE and run it again. The IDE will open all the MSDN-help pages inside dynamic bars and dock all the bars to their recent locations, but the IDE does not guarantee that each MSDN-help page will be created inside the same bar at the recent location. This means Visual Studio "knows" the number of resizable bars, types of windows/documents to open inside its dynamic bars (which may be not only of the MSDN-help page type) and the URL of each document but the IDE does not "know" which document corresponds to each dynamic resizable panel. This is not a bug. I assume this behavior of the bar state loading is a result of complexity of the UI design. If you have any problems with implementing dockable documents, I can offer you my help in coding your startup project or modifying the existing one. Best regards, Sergiy.
|
|