Forum

I have a MDI application with tabbed MDI childs. In CMainFrame::OnCreate I have the following code:

if(!m_wndMdiTabs.Create(this, CRect( 0, 0, 0, 0 ), UINT( IDC_STATIC ),    WS_HSCROLL | WS_VSCROLL | WS_CHILD | WS_VISIBLE |
            WS_CLIPSIBLINGS,
            __ETWS_ENABLED_BTN_CLOSE | __ETWS_SHOW_BTN_CLOSE |
            __ETWS_MDI_DEFAULT | __ETWS_ORIENT_TOP | __ETWS_AUTOHIDE_SCROLL |
            __ETWS_ITEM_DRAGGING | __ETWS_BOLD_SELECTION | __ETWS_HIDE_ICONS)
            //PUIS_TABWINDOWFROMDI - $$__PROFUISAPPWIZ_KEY_ADF_MDITABS$$
        )
    {
        ASSERT( FALSE );
        return -1;
    }
    m_wndMdiTabs.ModifyTabWndStyle( 0, __ETWS_SHOW_BTN_TAB_LIST | __ETWS_ENABLED_BTN_TAB_LIST);

I don’t know why, but the MDI tab close button appears disabled. If I click on it works (the child window is correctly closed). Is there something I can do to fix this issue ?

Ok. Problem fixed. Thank you. The style WS_SYSMENU was missing and I discovered Prof-UIS checks if System Menu exists.

The close button is not disabled and if I remove the TAB control using my application as a standard MDI aplication everything works fine. I think that for what ever reason there is something that disables the button, but I didn’t succeed to understand what.

#if (!defined __EXT_PROFUIS_STATIC_LINK || defined __EXT_PROFUIS_STATIC_LINK_WITH_RESOURCES)

    CExtLocalResourceHelper _LRH;
    CWinApp * pApp = ::AfxGetApp();
    ASSERT_VALID( pApp );
    m_hCursorResizingH =
        pApp->LoadCursor( MAKEINTRESOURCE( IDC_EXT_RESIZE_H1 ) );
    ASSERT( m_hCursorResizingH != NULL ); // ==> ASSERTION FAILED
    m_hCursorResizingV =
        pApp->LoadCursor( MAKEINTRESOURCE( IDC_EXT_RESIZE_V1 ) );
    ASSERT( m_hCursorResizingV != NULL );
#else

    m_hCursorResizingH =
        ::LoadCursor( NULL, IDC_SIZEWE );
    ASSERT( m_hCursorResizingH != NULL );
    m_hCursorResizingV =
        ::LoadCursor( NULL, IDC_SIZENS );
    ASSERT( m_hCursorResizingV != NULL );

#endif // #if (!defined __EXT_PROFUIS_STATIC_LINK || defined __EXT_PROFUIS

I knew why : How to link statically with Prof-UIS?

I wanna add prof-uis functions into non-prof-uis-appStudio-generated sample program.

The sample is driller(http://www.experts-exchange.com/Programming/Programming_Languages/MFC/Q_21463025.html).

After add <prof-uis.h> into stdafx.h, compile produce link error :
Linking...
XHtmlCtrl.obj : error LNK2001: unresolved external symbol "protected: static struct AFX_INTERFACEMAP const COleControlSite::interfaceMap" (?interfaceMap@COleControlSite@@1UAFX_INTERFACEMAP@@B)
..\..\DebugBin\WAdmin.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.

What is the problem? MSVC-80 worked well, but, I wanna use VC-60.

Static link works fine.

Please send us the .dsp file of your project so we can check the settings.

When I link using the static libraries, I have problems with the page navigator control. The tooltips flash, the hand cursor is not displayed, and the options dialog is not displayed. It appears as though these resources are not available to the application, and in debug mode, this causes an exception.
Is there anything else that needs to be done to use static linking other than select "MFC in static library"?

Thanks
Chris

Hello,
We have a problem in a top-level documents application created with VS 2005.
We’ve created a CExtControlBar in CMainFrame with AutoHide.
And we have problems with CExtControlBar redraw when this one is hidden.

Do you know what I need to do to solve this issue?

In my IE toolbar Impl I have the following problem: When I select a new window(browser instance) from the file menu in IE, the toolbar crashes. It seems that 2 ore more toolbars cant share the same process? I assume that this has somthing to do with g_CmdManager? I guessed that you cant create another identical toolbar in the same process and that you need a new profile for each toolbar, So i did that and I can get the toolbar to load and display for multiple instances but when I press any button I get an assert here:

void CExtToolControlBar::_CloseTrackingMenus()
{
    g_bMenuTracking = false;

//CSingleLock _slCsCB( &g_csCB );
//    _slCsCB.Lock();
    for( INT iBar=0; iBar<g_AllBars.GetSize(); ++iBar )
    {
        CExtControlBar * pBar = g_AllBars[iBar];
---->>        ASSERT_VALID( pBar );
        if( pBar->GetSafeHwnd() == NULL )
            continue;
        CExtToolControlBar * pToolControlBar =
            DYNAMIC_DOWNCAST(CExtToolControlBar,pBar);
        if( pToolControlBar == NULL )
            continue;
        pToolControlBar->_SwitchMenuTrackingIndex();
    }


Do you know what I need to do to solve this issue? I think you can duplicate this problem with that KBBar toolbar that I sent you.

I am still haveing this issue after static linking the MFC and profUIS. I am using a another dll that uses mfc in a dll, could this cause the problem? And what exactly is the problem?

If you use both MFC and the Prof-UIS RDE configuration as static libraries, there should not be any problems. All the global objects in this case are parts of your COM module instance. You can create several instances of your in-process COM object without any problems in this case. If you use Prof-UIS and MFC as DLLs, you can create only one instance of your com object in one process. The problem is in managing the state for global variables.

Call Stack FYI:


CWnd::AssertValid() line 883 + 67 bytes
CControlBar::AssertValid() line 986
CExtToolControlBar::AssertValid() line 8241
AfxAssertValidObject(const CObject * 0x02bb2ad8 {CRSAToolbarWnd}, const char * 0x029fe590 THIS_FILE, int 9389) line 108
CExtToolControlBar::_CloseTrackingMenus() line 9390
CExtBarButton::OnClick(CPoint {x=39 y=15}, unsigned char 1) line 2147
CExtToolControlBar::OnLButtonDown(unsigned int 1, CPoint {x=39 y=15}) line 7578 + 26 bytes
CWnd::OnWndMsg(unsigned int 513, unsigned int 1, long 983079, long * 0x04dbf818) line 1964
CWnd::WindowProc(unsigned int 513, unsigned int 1, long 983079) line 1585 + 30 bytes
CControlBar::WindowProc(unsigned int 513, unsigned int 1, long 983079) line 480 + 20 bytes
CExtControlBar::WindowProc(unsigned int 513, unsigned int 1, long 983079) line 6937
CExtToolControlBar::WindowProc(unsigned int 513, unsigned int 1, long 983079) line 9295
AfxCallWndProc(CWnd * 0x02bc0a48 {CRSAToolbarWnd hWnd=???}, HWND__ * 0x001c0db0, unsigned int 513, unsigned int 1, long 983079) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x001c0db0, unsigned int 513, unsigned int 1, long 983079) line 368
AfxWndProcDllStatic(HWND__ * 0x001c0db0, unsigned int 513, unsigned int 1, long 983079) line 57 + 21 bytes
USER32! 77d48734()
USER32! 77d48816()
USER32! 77d489cd()
USER32! 77d48a10()
BROWSEUI! 75fa6f6d()
BROWSEUI! 75fae942()
BROWSEUI! 75faeab5()
KERNEL32! 7c80b50b()

To resolve this problem, use both Prof-UIS and MFC libraries linked statically. Simply setup your project to use MFC as a static library. The Prof-UIS library will automatically be linked statically. Of course, you need to compile the appropriate configuration of the ProfUISLIB project.

This does not seem to solve the problem. There is on instance of the g_allbars per process it seems, When I select "new window" from ie it starts a new toolbar in a seperate thread but the gcommandmanager is the same copy etc, (all static vars are shared between threads) :

so it is checking g_Allbars[0] first which is a Cwd in another thread, ie the first toolbar instance, so I get the following assert:

Stack:

CWnd::AssertValid() line 883 + 67 bytes
CControlBar::AssertValid() line 986
CExtToolControlBar::AssertValid() line 8242
AfxAssertValidObject(const CObject * 0x0299c7f8 {RsaToolbar::CRSAToolbarWnd hWnd=0x00180d64}, const char * 0x028cd6e0 THIS_FILE, int 9390) line 108
CExtToolControlBar::_CloseTrackingMenus() line 9391
CExtBarButton::OnClick(CPoint {x=28 y=18}, unsigned char 1) line 2147
CExtToolControlBar::OnLButtonDown(unsigned int 1, CPoint {x=28 y=18}) line 7578 + 26 bytes
CWnd::OnWndMsg(unsigned int 513, unsigned int 1, long 1179676, long * 0x04b8f848) line 1964
CWnd::WindowProc(unsigned int 513, unsigned int 1, long 1179676) line 1585 + 30 bytes
CControlBar::WindowProc(unsigned int 513, unsigned int 1, long 1179676) line 480 + 20 bytes
CExtControlBar::WindowProc(unsigned int 513, unsigned int 1, long 1179676) line 6937
CExtToolControlBar::WindowProc(unsigned int 513, unsigned int 1, long 1179676) line 9296
AfxCallWndProc(CWnd * 0x02995698 {RsaToolbar::CRSAToolbarWnd hWnd=0x001b0d6a}, HWND__ * 0x001b0d6a, unsigned int 513, unsigned int 1, long 1179676) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x001b0d6a, unsigned int 513, unsigned int 1, long 1179676) line 368



in CWnd::AssertValid():

        ASSERT((p = pMap->LookupPermanent(m_hWnd)) != NULL ||
here-->            (p = pMap->LookupTemporary(m_hWnd)) != NULL);
        ASSERT((CWnd*)p == this); // must be us

        // Note: if either of the above asserts fire and you are
        // writing a multithreaded application, it is likely that
        // you have passed a C++ object from one thread to another
        // and have used that object in a way that was not intended.
        // (only simple inline wrapper functions should be used)
        //
        // In general, CWnd objects should be passed by HWND from
        // one thread to another. The receiving thread can wrap
        // the HWND with a CWnd object by using CWnd::FromHandle.
        //
        // It is dangerous to pass C++ objects from one thread to
        // another, unless the objects are designed to be used in
        // such a manner.

...


This problem seems to go away in release mode... but I need debug to work.

Any ideas?

We believe it’s possible to fix this problem. We need some time to debug this issue carefully. The fix should be based on checking the result of the CWnd::FromHandlePermanent() method’s invocation. Would you send us a simplified/stripped version of your project which produces the problem?

It seems to be a problem with the in-proc COM object. The static global data only gets one instance per process( the dll is loaded one time). It seems like the static members should be malloc’ed in some way, that way there would be seperate data for each instance of the com object.

Another behavior that I am seeing that I am sure is related: If I select a drop-down menu from one instance and go to the onther instance to select the menu I get the following assert here:

void CExtPopupMenuSite::_Done()
{
here-->    ASSERT( !m_bShutdownMode );
    if( m_pWndToolTip != NULL )
        m_pWndToolTip->Hide();
    m_bShutdownMode = true;
    m_pWndCapture = NULL;
    m_pWndAnimation = NULL;
    m_lpnResultCmdID = NULL;
    if( m_pTopMenu != NULL
...

_CrtDbgReport(int 2, const char * 0x028e62a8 THIS_FILE, int 567, const char * 0x00000000, const char * 0x00000000) line 353
AfxAssertFailedLine(const char * 0x028e62a8 THIS_FILE, int 567) line 39 + 19 bytes
CExtPopupMenuSite::_Done() line 567 + 39 bytes
CExtPopupMenuSite::DoneInstance() line 540
CExtPopupMenuWnd::OnCancelMode() line 11937
CWnd::OnWndMsg(unsigned int 31, unsigned int 0, long 0, long * 0x049ef184) line 1825
CWnd::WindowProc(unsigned int 31, unsigned int 0, long 0) line 1585 + 30 bytes
AfxCallWndProc(CWnd * 0x029af080 {CExtPopupMenuWnd hWnd=???}, HWND__ * 0x00510d10, unsigned int 31, unsigned int 0, long 0) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x00510d10, unsigned int 31, unsigned int 0, long 0) line 368
USER32! 77d48734()
USER32! 77d48816()
USER32! 77d489cd()
USER32! 77d496c7()
CWinThread::PumpMessage() line 853
CExtPopupMenuWnd::PassMsgLoop(unsigned char 0) line 8128 + 21 bytes
CExtPopupMenuWnd::TrackPopupMenu(unsigned long 2724, int 535, int 354, const tagRECT * 0x049ef550 {top=347 bottom=369 left=512 right=561}, void * 0x029a72a8, void (void *, CDC &, const CWnd &, const CRect &, int)* 0x0212c570 CExtToolControlBar::_CbPaintCombinedContent(void *, CDC &, const CWnd &, const CRect &, int), unsigned int * 0x049ef544, unsigned char 1) line 8103 + 11 bytes
CExtBarButton::OnTrackPopup(CPoint {x=535 y=354}, unsigned char 0, unsigned char 0) line 1962 + 58 bytes
CExtBarButton::OnClick(CPoint {x=23 y=8}, unsigned char 1) line 2159 + 28 bytes
CExtToolControlBar::OnLButtonDown(unsigned int 1, CPoint {x=23 y=8}) line 7578 + 26 bytes
CWnd::OnWndMsg(unsigned int 513, unsigned int 1, long 524311, long * 0x049ef848) line 1964
CWnd::WindowProc(unsigned int 513, unsigned int 1, long 524311) line 1585 + 30 bytes
CControlBar::WindowProc(unsigned int 513, unsigned int 1, long 524311) line 480 + 20 bytes
CExtControlBar::WindowProc(unsigned int 513, unsigned int 1, long 524311) line 6938
CExtToolControlBar::WindowProc(unsigned int 513, unsigned int 1, long 524311) line 9296
AfxCallWndProc(CWnd * 0x029a72a8 {RsaToolbar::CRSAToolbarWnd hWnd=???}, HWND__ * 0x00500bc8, unsigned int 513, unsigned int 1, long 524311) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x00500bc8, unsigned int 513, unsigned int 1, long 524311) line 368

Would you please give me a simple sample for this?

The subject is exist in the prof-uis help file.

I wanna add an edit box, and combo box into the toolbar - prof-uis app-wizard generated toolbar.
I followed your guide, but definitely, failed.
Combobox and editbox are not shown on the toolbar.

I think it’s a bug, am I right?
Sample program "FixedSizedPanels-m.exe" doesn’t work correctly.

When I drag a fixed size panel, the size of it becomes larger and larger. Eat all screen area.
If you don’t agree, I’ll send you some screen capture.

Best regards,

jb.

Would you send us your modified version of the FixedSizedPanels sample?

I didn’t do any change on the sample FixedSizedPanels.
Yesterday, I sent you the screen cam and my sample code.

We’ve just sent an e-mail with a test project to you.

Hello,
I have problems using CExtTabWnd control in my CExtResizableDialog class.
I have created CExtTabWnd derived class named CMyExtTabWnd and overrided
virtual bool OnTabWndSelectionChange( LONG nOldItemIndex, LONG nNewItemIndex, bool bPreSelectionTest )
as mentioned in help to monitor tab changing...

But if any tab is clicked (selected) or when I call SelectionSet method, I get STACK OVERFLOW exception. If I use CExtTabWnd class directly, everything
seems ok, but I cannot monitor tab changes...

So, can you tell me what am I doing wrong?

We may guess that your overridden method is getting into an infinite loop. Please make sure that you are not invoking it itself instead of the base class method.

Thank you - that was it, i used your code from help and forgot to add base class identifier...

I’ve implemented an owner-draw, variable item height CExtComboBox control in a dialogue, and found that the Prof-UIS drop button sometimes only partially covers the standard Windows combobox button. (The standard button is not visible during a mouse hover.)

I’ll send a small PNG screenshot in an email.

This looks like a bug in the Prof-UIS code.

I have a CExtLabel that is loaded in a tollbar. How can I resize the text contained in that control, and have the toolbar and the control resize accordingly?

Is there a way to resize a docked CExtControlBar from the program?

SetInitDesiredSize...() followed by RecalcLayout does something, but only if the bar is on a single row.

If there are more than one control bar in the a row, you need to set a size for each control bar in this row. It is because control bars may affect each other’s size. Please provide us with more details about the layout so that we can help you.

What I would like to do is to add a command that attempts to ensure a minimum size for all the dynamic bars that are currently docked.

The CFrameWnd::m_listControlBars property contains a list of all the CControlBar objects in the frame window. You can traverse this list and downcast each control bar to the CExtControlBar type. If CExtControlBar::IsFixedMode() returns true, this bar is typically re-dockable toolbar and you should not review it. If the CControlBar::m_pDockSite property is set to NULL, then the control bar is not enabled for redocking and you should not review it too. The rest of the bars are resizable control bars including dynamic row containers (the CExtDynControlBar class) and dynamic tabbed container bars (the CExtDynTabControlBar class). We guess we may also review bars which are inside simple or complex floating palettes. This can be detected by invoking the GetParentFrame() method of the resizable control bar and analyzing whether it is CControlBar::m_pDockSite. Ok, the rest of bars should be reviewed and checked whether they have a minimal size. First of all, you need to invoke the CExtControlBar::IsDockedHorizontally() method to detect whether the bar is in a horizontal row of bars (or in a vertical column). To get the minimal height of the bar, use the CExtControlBar::_CalcDesiredMinVH() method and to get the minimal width of the bar, use the CExtControlBar::_CalcDesiredMinHW() method. The returned value can be compared with the real sizes of the control bar windows and you can reset the desired sizes to needed less possible. Please note, the default minimal sizes are very small and we recommend you hide some or all of bars instead of resetting their sizes to minimal possible.

Thank you for the explanation.
Once I have determined that a bar should be resized, what methos should I call? SetInitDesiredSize...() or another one?

How can you remove columns from the CExtTreeGridWnd?
Regards,
Eddie

The CExtGridWnd::ColumnRemove() method removes a column(s) both from CExtGridWnd and CExtTreeGridWnd controls.

When ever I try that I get an assert from the following location:
bool CExtTreeGridDataProvider::ColumnRemove(
    ULONG nColNo,
    ULONG nRemoveCount // = 1
    )
{
    ASSERT_VALID( this );
    nColNo;
    nRemoveCount;
    // this method must never be invoked
    ASSERT( FALSE );
    return false;
}

Not it’s understandable what you want. The CExtTreeGridDataProvider::ColumnRemove() method should redirect its call to the internall cache data provider as it is done in the CExtTreeGridDataProvider::ColumnInsert() method:

bool CExtTreeGridDataProvider::ColumnRemove(
    ULONG nColNo,
    ULONG nRemoveCount // = 1
    )
{
    ASSERT_VALID( this );
CExtGridDataProvider & _DP = _Tree_GetCacheDP();
    return _DP.ColumnRemove( _Tree_MapColToCache( nColNo ), nRemoveCount );
}

What is the propper way to insert and remove a button with a control on it and be able to do the insert/remove cycle over and over... What I want to do is keep the contol alive and show it in the toolbar on demand. If I just call RemoveButton the control stays on the toolbar. I tried using DestoryWindow() but when I call CreateWindow for the second time contol shows up as a grey inactive box.

My code seems to work with a CStatic but not with a CExtEdit.

Any Ideas?

For Example:


CExtEdit *m_wndPinEditBox;

void SomeClass::RemoveButton(UINT nCmdID)
{
    int nButtonIndex =
        m_wndToolBar->CommandToIndex( nCmdID );
    if( nButtonIndex >= 0 ){
        //if it is a control we need to hide the window
        CWnd* ctl = m_wndToolBar->GetButtonCtrl(nButtonIndex);
        if(ctl != NULL){
            ictl->DestroyWindow();        
        }
        m_wndToolBar->RemoveButton( nButtonIndex );
    }
    RecalcLayout();
}


bool SomeClass::InsertEditBox(int index)
{

    if(!m_wndPinEditBox->GetSafeHwnd( )) //Is this the correct way to test if the window is created?
    {
        if( !m_wndPinEditBox->CreateEx(
            WS_EX_CLIENTEDGE ,
            _T("EDIT"),
            NULL,
            WS_CHILD|WS_VISIBLE|WS_TABSTOP|ES_AUTOHSCROLL|ES_LEFT|ES_PASSWORD,
            CRect( 0, 0, 50, 21 ),
            m_wndToolBar,
            ID_PIN_EDIT
            )
            
            )
        {
            TRACE0("Failed to create help search combobox\n" );
            return false;
        }
    }
if(!m_wndToolBar->InsertButton
        (
        index,
        nID,TRUE
        )
        )return false;
    
    
    VERIFY(
        m_wndToolBar->SetButtonCtrl(
        m_wndToolBar->CommandToIndex(
        nID ),
        m_wndPinEditBox
        )
        );
}

nID in the example is ID_PIN_EDIT...

Hello,

I am trying to make a custom cell based on CExtGridCellDropListComboBox. For some reason it complains on compiling when I use the IMPLEMENT_DYNCREATE macro?


Any thoughts?

Also how do I intercept the selection changes of the combo box?

Thanks

Thanks!

I guess sometimes when you are looking at your ow code all day you get blurry eyed.

M

I should add:

1) I understand the last error and I removed the propertyItem initialization and I still get the other errors

2) If I remove DECLARE_DYNCREATE and IMPLEMENT_DYNCREATE it compiles and works I just can’t seem to intercept OnPopupListBoxSelEndOK()

Please ensure that you overrode OnPopupListBoxSelEndOK() in this way:

//   *.h file:

 virtual bool OnPopupListBoxSelEndOK(
  CExtPopupInplaceListBox & wndListBox,
  CExtGridCell::TrackCellStateInfo_t & _tcsi
  );


//   *.cpp file:

bool PropertyItemRequestCellCombo::OnPopupListBoxSelEndOK(
 CExtPopupInplaceListBox & wndListBox,
 CExtGridCell::TrackCellStateInfo_t & _tcsi
 )
{
 ASSERT_VALID( this );
 ASSERT( (&_tcsi.m_cell) == this );
 ASSERT_VALID( (&wndListBox) );
 ASSERT_VALID( (&_tcsi.m_wndGrid) );
 
 CExtGridCellDropListComboBox::OnPopupListBoxSelEndOK(
  wndListBox,
  _tcsi
  );
 
 // place your code
 
 return false;
}

Hmm... This didn’t seem to work? I am not sure what is going on here are the exact details:

//------------------
// Header file
//------------------
#pragma once

class PropertyItemRequestCellCombo :
    public CExtGridCellDropListComboBox
{
public:

    DECLARE_DYNCREATE( PropertyItemRequestCellComboCombo );
    IMPLEMENT_ExtGridCell_Clone( PropertyItemRequestCellCombo, CExtGridCellDropListComboBox );

    PropertyItemRequestCellCombo(CExtGridDataProvider * pDP = NULL);
    ~PropertyItemRequestCellCombo(void);

};

//------------------
// CPP file
//------------------

#include "StdAfx.h"
#include ".\PropertyItemRequestCellCombo.h"

IMPLEMENT_DYNCREATE(PropertyItemRequestCellCombo, CExtGridCellDropListComboBox );

PropertyItemRequestCellCombo::PropertyItemRequestCellCombo(CExtGridDataProvider * pDP)
    : CExtGridCellDropListComboBox( pDP ),
    propertyItem(NULL)
{
}

PropertyItemRequestCellCombo::~PropertyItemRequestCellCombo(void)
{
}

//------------------------------------------------
//------------------------------------------------
And when I compile (VS .net) I get the following errors:

PropertyItemRequestCellCombo.cpp(6) : error C2039: ’classPropertyItemRequestCellCombo’ : is not a member of ’PropertyItemRequestCellCombo’
PropertyItemRequestCellCombo.h(5) : see declaration of ’PropertyItemRequestCellCombo’
PropertyItemRequestCellCombo.cpp(6) : error C2496: ’classPropertyItemRequestCellCombo’ : ’selectany’ can only be applied to data items with external linkage
PropertyItemRequestCellCombo.cpp(6) : error C2039: ’classPropertyItemRequestCellCombo’ : is not a member of ’PropertyItemRequestCellCombo’
PropertyItemRequestCellCombo.h(5) : see declaration of ’PropertyItemRequestCellCombo’
PropertyItemRequestCellCombo.cpp(6) : error C2039: ’classPropertyItemRequestCellCombo’ : is not a member of ’PropertyItemRequestCellCombo’
PropertyItemRequestCellCombo.h(5) : see declaration of ’PropertyItemRequestCellCombo’
PropertyItemRequestCellCombo.cpp(11) : error C2614: ’PropertyItemRequestCellCombo’ : illegal member initialization: ’propertyItem’ is not a base or member

It seems the problem is trivial. There is a redundant "combo":

DECLARE_DYNCREATE( PropertyItemRequestCellComboCombo );

In fact, it should be:

DECLARE_DYNCREATE( PropertyItemRequestCellCombo );

We know only one problem with IMPLEMENT_DYNCREATE and grid cells. This problem is caused by a conflict of C++ new operators defined locally in the CExtGridCell class. The solution is really easy. Please open the C++ file that implements your cell class and move the IMPLEMENT_DYNCREATE macro to the top of the file before the definition of the debug version of the new operator:

#include "StdAfx.h"
. . .
IMPLEMENT_SERIAL(...
. . .
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
. . .

As for the selection changed event, you need to override the OnPopupListBoxSelEndOK() virtual method, which is called to handle the final item selection changed event of the list box control in the popup menu tracked by the built-in button.

I think it is a bug of Prof-UIS 2.53. Please fix it ASAP.

MDIDOCVIEW-m.exe in your sample is working well in the first time but from the second time the Color picker lose its border.
If you resize the Color picker then it regain its border correctly.

Thanks always for your help

Thank you for the bug report. Please contact us by e-mail so we can provide you with a bug fix.

I get an assert in ProfUIS 2.53 in extpaintmanager.cpp, line 23028 function CreateFromBitmapResources()

The eDockMarkerType is __EMDT_2005_TOP. I’m guessing that I’m missing resource information somehow.
The software I am using was built on an older version of profuis, version 2.50. Has anything changed that I should be aware of?

NT

I think this is related to the __EXT_PROFUIS_STATIC_LINK_WITH_RESOURCES flag.
Also, I noticed my profuis project had no resource files. My guess is that its trying to draw the bitmaps for docking but can’t.

NT

Just to add, I’m getting the assert when dragging the windows.

We guess you forgot to add the following lines into the .rc2 file of your project:

#if ( !(defined _AFXDLL && !defined __STATPROFUIS_WITH_DLLMFC__) )
    #include <Resources/Resource.rc>
#endif

This is also described in the FAQ How to link statically with Prof-UIS?.

I think the previous version of profuis I had, used internally defined globals for resources. They were no longer active in the current release. I tried commenting out __EXT_PROFUIS_STATIC_LINK_WITH_RESOURCES but then got a compile error ... something wasn’t defined in on of the files (some global).

Putting the lines you suggested didn’t work, I’m not sure why. However putting #include <Resources/resource.rc> by itself seemed to work fine.
As a side note, a new project created with the wizard also asserted during dragging. Would I have to include this in every project I create from now on?

NT

When my MDI Childs are in tabbed mode, Ctrl-Tab flips through the childs backward and Ctrl-Shift-Tab forward. What have I done wrong?

Thanks in advance

Thomas

By default, an MFC MDI project generated with the wizard has (in the accelerator table) the ID_NEXT_PANE command associated with F6 and ID_PREV_PANE associated with Ctrl+F6. The Ctrl+TAB and Ctrl+Shift+TAB key combinations should work in your application without any keyboard accelerator assignments. All the key combinations work OK in our MDI sample. Any of them may not work due to some message pre-translation performed in your application. We can help you by reviewing your project and figuring out what’s wrong. You can also put some debug code lines into your CMainFrame::PreTranslateMessage() method to detect the pressing of the Ctrl+Shift+TAB key combination. This will allow you to trace the message pre-translation route and find out which component eats this event.

Hello

Thanks for your answer. The Keyboard events got eaten by a call to TranslateMDISysAccel in CMDIFrameWnd::PreTranslateMessage. The call to TranslateMDISysAccel returns TRUE but the message is still the same (I expected it to be something with WM_COMMAND afterwards). It seems that if I do have an entry in the accelerator table it does not get looked at (I tried to fix the problem the cheap way by just switching the accelerators for ID_PREV_PANE and ID_NEXT_PANE but without effect). Do you have any other suggestions what I could look at? Thanks in advance.

Thomas

You can simply use your own two custom command identifiers for implementing the MDI Next/Prev window switching. This simple and direct solution will work independently from any conditions. Your methods should simply send the WM_MDINEXT standard Windows message to the MDI client window.

Hello

Thank you for your answer. Believe it or not, sending a WM_MDINEXT to the client does it wrong (= works like WM_MDIPREV is supposed to). It doesn’t seem to be a problem of the keyboard but of interpreting this message.

Thanks in advance

Thomas

Please check once more in which way you send this message:

HWND hWndMdiClient = ::GetDlgItem( pMainFrame->GetSafeHwnd(), AFX_IDW_PANE_FIRST );
 
    ::SendMessage( hWndMdiClient, WM_MDINEXT, 0, 0 ); // activate next
    ::SendMessage( hWndMdiClient, WM_MDINEXT, 0, 1 ); // activate previous

My message was misleading because I wrote about the non existing WM_MDIPREV. What I really did for experimental reasons: I just called CMDIFrameWnd::MDINext and it switched to the previous MDI window.

Meanwhile I had to solve the problem by handling Ctrl-Tab and Ctrl-Shift-Tab in PreTranslateMessage and call MDINext in case of Ctrl-Shift-Tab and MDIPrev in case of Ctrl-Tab and it works fine but it remains a mystery to me.

I never consciously changed anything about this feature (neither in keyboard handling nor in MDI child handling).

Well I guess my workaround will have to do. If you have any ideas or if you would want to look deeper into the problem because other customers of yours might run into the same problem I will gladly assist and provide more information.

Thank you for your assistance

Thomas

CExtToolControlBar and its child controls don’t seem to manage the input focus correctly.

For example, when I create a text formatting toolbar with font name and font size combobox child controls (as in your Style Editor example), selecting a font name or a font size captures and fails to restore the input focus from whatever previously had it (eg. the current view).

The expected mode of behaviour is that a focus child window retains the (apparent) focus during a selection and restores it after a toolbar selection is made.

Colour selection buttons perform as expected when their parent toolbar is docked, but not when it is floating. I’ve yet to check whether other buttons behave similarly.

The Style Editor example fails to reveal this limitation because its view is passive.

I’m preparing a work-around for this problem in my application, but it is a poor substitute for correct behaviour.

Can you suggest a way in which I can have CExtToolControlBar ensure that its child controls restore the input focus without my altering the CExtToolControlBar source code?

You wrote in another thread:"Additionally we advise you to change the design of your IE embedded bar because Prof-UIS toolbars have a different style. It is possible to subclass the IE-bar which is inserted directly into the rebar common control. You can subclass the IE toolbar window with the CExtToolControlBar class. As a result you will have a solid Prof-UIS-based bar inside IE."

Could you elaborate on this? Is there a way to inherit the rendering mode of the "system" so the style always matches IE?

We mean that it is possible to subclass the IE rebar band window which looks like a toolbar with the current windows style. After subclassing this bar and its content, it will have a solid look of any theme supported in Prof-UIS. But, as a result, you will get an IE toolbar with the style different to all other IE toolbars.

Could you give me a simple class declaration of what you mean?

Are you saying that I should not use the CExtToolControlBar? that I cant make it look like a standard ie toolbar? Sorry for being so thick...

We did the trick and now the background of your IE toolbar is drawn correctly. Please declare a CExtToolControlBar-derived class (e.g. CKBToolbarWnd) and override the DoEraseBk() virtual method in this way (the full source code can be downloaded from here):

void CKBToolbarWnd::DoEraseBk( CDC * pDC )
{
 ASSERT( pDC->GetSafeHdc() != NULL );
 
CRect rcClient;
 GetClientRect( &rcClient );
 
 if( ::IsRectEmpty( &rcClient )
  || ( ! pDC->RectVisible( &rcClient ) )
  )
  return;
 
CWnd * pWndParent = GetParent();
 ASSERT( pWndParent != NULL );
 ASSERT_VALID( pWndParent );
 
CRect rcParentWnd;
 pWndParent->GetWindowRect( &rcParentWnd );
 ScreenToClient( &rcParentWnd );
 
bool bDefaultDrawing = true;
 if(  g_PaintManager.m_UxTheme.IsAppThemed()
  && g_PaintManager.m_UxTheme.IsThemeActive()
  && g_PaintManager.m_UxTheme.OpenThemeData(
    GetSafeHwnd(),
    L"REBAR"
    ) != NULL
  )
 {
  INT nPartID = 0;
  INT nStateID = 0;
  if( g_PaintManager.m_UxTheme.DrawThemeBackground(
    pDC->GetSafeHdc(), 
    nPartID, 
    nStateID, 
    &rcParentWnd, 
    &rcClient
    ) == S_OK
   )
   bDefaultDrawing = false;
  g_PaintManager.m_UxTheme.CloseThemeData( true );
 }
 
 if( bDefaultDrawing )
  pDC->FillSolidRect(
   &rcClient,
   ::GetSysColor( COLOR_3DFACE )
   );
}

I have a CExtCmdItem object set as combo on the menu bar, but when it displays the drop-down list the height of the list is fixed and it’s too big. Is there the possibility to have a drop-down list with dynamic height that can fit the number of contained items as a standard Windows combo control ?