Forum

Hi,

I use a subwindow that setup its own profile. In that window, I have some docked toolbars that work fines. But, if I try to move one of them to change its state to floating mode, I get an assertion on line 451 of the ExtToolControlBar.cpp. (v2.40) The assertion validate a command item pointer. I just don’t understand why it cannot find it if my toolbar becomes in floating mode. The problem happend on the OnPaint method of a CExtBarButton. All my toolbars implement a combo box or a slider. So, any idea?? Do I forgot the setup something in the command manager?

Tanks

Each command profile in the command manager has one or more HWND handles associated with this profile. Typically it is an HWND handle to the main frame window. The command profile searching algorithm for any window is based on iterating over HWNDs both to this window and to all its parent windows until some handle is not found in some command profile in the command manager. The floating mini frame window with toolbars is a child of the main frame window in a simple frame-based MFÑ application. So, each toolbar window can walk through its parents and stop at the main frame window whose HWND is used in the command manager’s profile. In your case, the frame window is not a top level pop-up window. The floating mini frame window with toolbars has the parent window which contains your frame window somewhere inside. So, any toolbar in the floating state is unable to use the command manager. The solution to this problem is very simple: add HWND of the top level frame window to the same command profile which is initialized for your standalone frame window. Here is how your command profile initialization in the CYourFrame::OnCreate() method may look like:

int CYourFrame::OnCreate( LPCREATESTRUCT lpCreateStruct )
{
    if( CBaseOfYourFrame::OnCreate( lpCreateStruct ) == -1)
        return -1;
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’) );
    ASSERT( pApp->m_pszProfileName != NULL );
    g_CmdManager->ProfileSetup(
        pApp->m_pszProfileName,
        GetSafeHwnd()
        );
    g_CmdManager->ProfileSetup( // !!! IMPORTANT !!!
        pApp->m_pszProfileName,
        GetTopLevelParent()->GetSafeHwnd()
        );
    . . .

Of course, you should remove both HWND handles from the command profile in the CYourFrame::DestroyWindow() method. The CExtCmdManager::ProfileWndRemove() allows you to deallocate the command profile and destroy all the icons and command descriptions when removing the last HWND handle from this profile. Invoke this method for both HWND handles and specify true in the bRemoveProfileIfLastHWND parameter.

The solution described above is essential when you code an ActiveX component which looks like an independent frame window with dockable bars inside. The very same approach is used in the Prof-UIS Frame Features ActiveX control.

Tanks. It works!

Unfortunately I don’t know the solution for the problem, but almost the same happens for me, too. But when I remove the customization from my project, it works again. So might be something about that. Even though, I eagerly wait for the answer, too. Chris

I doesn’t use the customization subsystem yet. Maybe you should check to register top level parent in your profiler like they suggested to me.