Forum

Hi,

When I try to call     
g_CmdManager->SerializeState(    
        __PROF_UIS_PROJECT_CMD_PROFILE_NAME,
        pApp->m_pszRegistryKey,
        pApp->m_pszProfileName,
        false );
I get an debug assertion in ExtCmdManager.cpp line 3462. My debugger does not show the source code. I do this call after I created the CExtControlBars and their contents.

If I skip the call to SerializeState() and call ProfileBarStateLoad() right away then I get an assertion in winfrm2.cpp line 99 in DockControlBar(CControlBar* pBar, CDockBar* pDockBar, LPCRECT lpRect). The first 5 times it works find because of some hardcoded loop 0..4 in this function. Does this mean I can have 5 toolbars at most? I have 7 toolbars now and have plans on making more.

If I do not try to serialize/load the states of the frames the app works fine.

Jos

All the control bars must have unique identifiers, but the code snippet in your message does not contain any information about duplicated identifiers. These two message map entries are absolutely OK. The first one binds a command handler method for showing/hiding a control bar. The second one binds a command updating handler for enabling a control bar showing/hiding a command and setting on/off its checked state.

You can send us your project to support@prof-uis.com.

I found a double id, and I added some of those
    ON_COMMAND_EX(ID_ANALYZER_BAR, OnBarCheck)
    ON_UPDATE_COMMAND_UI(ID_ANALYZER_BAR, OnUpdateControlBarMenu)
However I still have the same errors.

Can you tell how how I should send the source codes to you.

Regards, Jos.

You can count on our help and assistance. But sometimes it is more efficient and time-saving to look at your code. This would allow us to avoid making guesses about what may be wrong.

I’m relatively new to MFC and ProfUIS. I added ProfUIS functionality to an exsisting program. I will try to follow all tips you give me. I will not finish that today. Btw. meanwhile I implemented dockbar persistency myself, it works pretty good and the registry is more readable. However, if my app is a mess I need to clean it up anyway otherwise I can expect more problems in the future. I keep your offer to send you the project in mind in case I don’t manage to do what is needed, but I rather do it myself because I have to learn this stuff.

Thanks for the answers.

Suhai,

Thank you for answering my question.

I tried solutions 1 and 2. Alas they do not help me. When the asserts are ignored (in release mode) it ends up in an exception anyway.

No matter what I try. The only time there is no exception is when the registry is empty and I run ProfileBarStateLoad() first. As soon as the program has run once and the registry is filled again by ProfileBarStateSave() I get the problems. SerializeState() never ran without an error.

So must be something very wrong with my app. I also commented out the three VERIFY(g_CmdManager-> ... ); in the beginning of my CMainFrame::OnCreate() they also gave me asserts.

Jos

Please ensure all the commands in all the menus and toolbars in your application are registered in the command manager. This means you should update the command manager from all the menus and toolbar resources used in your project. Please also note all the control bars (menu bar, status bar, toolbars, panel bars and resizable control bars) should be created using unique dialog control identifiers which should be exactly the same as command identifiers for showing/hiding control bars in the menu. In any case, you can send us your project so we can clarify what is wrong.

If those 3 VERIFYs fail, then there is really something very wrong in your app. Have you followed the Feature Article "Getting started with ProfUIS"?
Can you make a very small app which reproduces the problem and has only the very basic GUI code? (Maybe ProfUIS Application Wizard can help you).

ProfileBarStateSave saves some info of its controlbars in the registry in binary format. SerializeState in DestroyWindow does the same for the commands in the command manager. If, during development, you change the IDs or the number of the commands or the bars, ProfileBarStateLoad and/or SerializeState won’t be able to load the state back from the registry. In debug mode this causes an assertion. But both ProfileBarStateLoad and SerializeState now have a parameter, bEnableThrowExceptions, if you set this to true, you can catch the thrown exception and load a default state.

Solution1: Delete the appropiate registry keys from registry,
Solution2: Run sample in release mode once. Release mode won’t throw assertion on ProfileBarStateLoad and saves the right state when closing the application,
Solution3: Set bEnableThrowExceptions parameter to true and handle the thrown exception.