Professional UI Solutions
Site Map   /  Register
 
 

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.

Forums » Prof-UIS Tech Support » Bug in CExtCmdProfile::SerializeState when loading Collapse All
Subject Author Date
Offer Har Nov 13, 2008 - 5:13 AM

Hi,


I have a set of toolbars and control-bars that are serialized when the application terminates.


All works well untill I hide one of the control-bars. When I ssrialize the satte of the UI after I hide the control-bar, next time I load the UI I get assertion and later a crash in CExtCmdProfile::SerializeState, line :1870 (2.84 of 11-11)



            for( ; true; )
            {
                UINT nCmdId, nUsageTickCount;
                ar >> dwTmp;
                nCmdId = UINT(dwTmp);
                if( nCmdId == 0 )
                    break;
                ar >> dwTmp;
                nUsageTickCount = UINT(dwTmp);
                CExtCmdItem * pCmdItem = CmdGetPtr(nCmdId);
                ASSERT( pCmdItem != NULL ); <-- HERE
                if(        pCmdItem->StateIsBasic()
                    ||    pCmdItem->StateIsForceRarely()
                    ||    CExtCmdManager::IsSystemCommand(pCmdItem->m_nCmdID)
                    )
                    continue;
                pCmdItem->m_nUsageTickCount = nUsageTickCount;
            }

The ID that is being looked (nCmdId) for and not found is the ID of the control-bar that was hidden when the UI state was saved. Please verify and fix this.


Thanks.


 


 

Technical Support Nov 14, 2008 - 12:14 PM

This issue sounds like very critical. Most of Prof-UIS based applications have control bars and, of course, some of them always become hidden at shutdown and next startup. But nobody has reported any problems with loading hidden bar states yet. We recommend you to check whether the shutdown/startup code in your application looks like the same code in our samples. Please do not mix method invocations because neither Prof-UIS nor other libraries can work OK if the API invocations done in the incorrect order.

Offer Har Nov 17, 2008 - 9:54 AM

Dear support,


I need assitance with this one, as this is very critical.


This is my load & save code:


 


bool CMainFrm::LoadState() {     if (m_bLoadState)     {         CWinApp * pApp = ::AfxGetApp();         ASSERT( pApp != NULL );         ASSERT( pApp->m_pszRegistryKey != NULL );         ASSERT( pApp->m_pszRegistryKey[0] != _T(’\0’) );         ASSERT( pApp->m_pszProfileName != NULL );         ASSERT( pApp->m_pszProfileName[0] != _T(’\0’) );         VERIFY(         CExtControlBar::ProfileBarStateLoad(             this,             pApp->m_pszRegistryKey,             pApp->m_pszProfileName,             pApp->m_pszProfileName,             &m_dataFrameWP             ));         VERIFY(         g_CmdManager->SerializeState(             m_strProfileName,             pApp->m_pszRegistryKey,             pApp->m_pszProfileName,             false             ));     }     return true; } bool CMainFrm::SaveState() {     CWinApp * pApp = ::AfxGetApp();     ASSERT( pApp != NULL );     ASSERT( pApp->m_pszRegistryKey != NULL );     ASSERT( pApp->m_pszRegistryKey[0] != _T(’\0’) );     ASSERT( pApp->m_pszProfileName != NULL );     ASSERT( pApp->m_pszProfileName[0] != _T(’\0’) );     VERIFY(     CExtControlBar::ProfileBarStateSave(         this,         pApp->m_pszRegistryKey,         pApp->m_pszProfileName,         pApp->m_pszProfileName,         &m_dataFrameWP         ));     VERIFY(     g_CmdManager->SerializeState(         m_strProfileName,         pApp->m_pszRegistryKey,         pApp->m_pszProfileName,         true         ));     g_CmdManager->ProfileWndRemove( GetSafeHwnd() );     return true; }


What & where else can I look to track down this bug? I realy don’t know where to start looking.


How come the command is not recognized when the application is loading? where do I remove a command from the command manager? I do not handle the closing of the control-bar in any special way - just the noraml OnBarCheck:


 


BOOL CMainFrm::OnBarCheck(UINT nID) {     return CExtControlBar::DoFrameBarCheckCmd(this, GetSmallID(nID), true); }


Thanks.

Technical Support Nov 17, 2008 - 1:46 PM

Your code can remove one or several particular commands by invoking the following APIs:

CExtCmdManager::CmdRemove()
CExtCmdManager::CmdRemoveByMask()
CExtCmdProfile::CmdRemove()
CExtCmdProfile::CmdRemoveByMask()
But these APIs are very rarely used in real life applications. There is much more common error related to command manager command registration: the application registers a different set of commands in the command manager during different startup times. This is the thing you should really check. It’s a very common error. Please ensure your application updates the command manager from the same toolbar and menu resources each time it starts. Please ensure all the menu resources used as context menus were used for updating the command manager at early startup where you updated it from main frame and/or document/view menu resources.

Offer Har Nov 17, 2008 - 4:24 PM

Dear Support,


We know that this is a common problem, and for that we implemented the following mechanism:


If the application crashes when loading the UI state, we start it up using a command-line argument that does not load the UI state, and then when it is closed it saves the new UI state.


This concept helps us when customers report crash at startup, we just tell them to load without the loading of the UI state, and even if we in-house have conflicting versions this is what we do.


However, even so, If we do this:


1) Start the application without any loading of UI state


2) Hide a control bar (by pressing its ’x’ button)


3) Close the application, which saves the UI state to the registry.


4) Run the application with loading of the UI state


We get a crash - there was no change in the code or UI whatsoever.


Please help...


Thanks,


Ron.

Technical Support Nov 14, 2008 - 12:13 PM

No. We currently support only binary formats both for file and registry based state serializations.

Technical Support Nov 13, 2008 - 1:27 PM

This unwanted assertion is not a crash. It’s incorrect usage of the Prof-UIS command manager. If the command manager loads the command state, all commands presented during the last state saving should be already registered in it. Please check whether the command manager is updated from all menus and toolbars used in your project before loading its state. The problem can also occur during development when you are simply adding new commands, removing some commands or changing command identifiers

Offer Har Nov 14, 2008 - 7:30 AM

I also asked if there is a way to save the UI state to a file and not registry, and in a text format and not binary so I can look and see what is messed up there. So, is it possible?

Offer Har Nov 13, 2008 - 1:30 PM

Dear Support,


1) This happened in a test environment, and not during development.


2) This only happened with control-bars that were hidden and then the UI was saved, and then re-loaded.


It looks like when the bars were hidden and then the UI is re-loaded, something get messedup in the loader. Please check.