Forum

Hi! In Prof-UIS we save and load all the toolbars and menubars settings (and others) to the registry. But when I change something (like adding a new command) in the menu or toolbar (not dynamically but in the application) at the next running of the program I usually get an abort or assertion failure. Right now I can fix the problem only if I remove the profile from the registry. Isn’t there any other way of fixing the problem? Thank you: Chris.

This question is related to code design. The assertion occurs when the registry state does not describe exact state of the bars in the application. This is just an assertion in the debug version and nothing more. Maybe we need to replace ASSERT( FALSE ) in the catch section to something like TRACE("Warning! The Prof-UIS control bar state being loaded does not match the control bars created in the frame window!\n"). We would appreciate if you share your point of view on this issue with us.

In our opinion the best solution would be replacing "ASSERT( FALSE )" with a code that ignores all control bar settings in case of unmatch. TRACE is OK but the user of the application will not see it. We’d say rather lose all settings if the application can run fine without them. Regular users will not understand what causes the abort and might think of a much bigger problem.

We have replaced ASSERT with TRACE. The OnCreate() method of your application now should have the following lines:

    if( ! CExtControlBar::ProfileBarStateLoad( . . . ) )
    {
        DockControlBar( &m_wndMenuBar );
        DockControlBar( &m_wndToolBar );
        . . .
 
        m_wndResizableBar1.DockControlBar. . .( . . . );
        m_wndResizableBar2.DockControlBar. . .( . . . );
        m_wndResizableBar3.DockControlBar. . .( . . . );
 
        . . .
    }

If the control bars’ state has not been loaded, your code has no reason to think about whether the bars’ state is present in the registry or it is invalid.