Forum

Hello there,

i’m newbie in mfc so apologize if my question might be silly. I’ve defined a CExtResizableDialog. For this i designed a dialog in the resources manager which contains 1 combobox , 3 Radiobutton and 1 GroupBox. i casted the combobox and the 3 radio button to their Ext version properly.

BUT for the groupbox, i’d like to display a CExtScrollWnd instead, i casted the ’groupbox’ m_PicMemory to CExtScrollWnd
    CExtScrollWnd    m_PicMemory;
    CExtComboBox    m_CmbLocation;
    CExtRadioButton    m_RadByte;
    CExtRadioButton    m_RadWord;
    CExtRadioButton    m_RadDword;

i ’ve also a anchor to the CExtScrollWnd , so it grows properly with the windows
AddAnchor(IDC_MEMORY, CPoint(0,0), CPoint(100,100));

Here’s my problem, if i do the casting to CExtScrollWnd for the GroupBox, all the drawing are rubbish for the whole dialog. With a cast to CExtGroupBox all is working fine. So my question is how can i add my CExtScrollWnd to my dialog ??? do i need to create it dynamicly ? if so, how can i do it ? and how can i add anchor to it ?

thanks in advance

pascal

Adding a variable for a control on your dialog resource into your CDialog-derived C++ class is called subclassing. In most cases only standard common controls available in the designer palette need to be subclassed. But you can implement a custom control using the designer and subclass it. The user control item on the dialog designer’s palette is used for creating any non-standard controls on the dialog. The properties of the user control dropped on the dialog include several advanced fields like the window class name. You should know both window class name string and C++ class name to create and subclass a custom control on the dialog. For instance, the IDD_PAGE_TOOLBARS dialog resource in the ProfUIS_Controls sample application includes several user controls with the "ProfUIS-ControlBar" window class name. These controls are subclassed with the CExtToolControlBar objects. The CExtToolControlBar class in Prof-UIS implements a toolbar. Creation of custom dialog control on the dialog template resource is similar to a standard common control. But you should add a dialog variable and one line of code using this variable and dialog control identifier in the DoDataExchange() virtual method of your dialog C++ class manually.

Please also note that an MFC based C++ class which implements some control can be designed in the following way:

1) This class may be an extended version of the standard common control or simply based on some standard common control. In this case the user control on the dialog template is not needed. The CExtButton class is the extended version of the button common control. The CExtColorCtrl class is a new independent color picker control, but we did not define a new window class name string for it and often used the CExtColorCtrl variable to subclass the simple button control. This is not a problem and you will never see a button subclassed by color control because the CExtColorCtrl class handles all the painting, mouse and keyboard events.

2) This class may be a non-standard control which defines and uses its own window class name. The user control should be used on the dialog template resource like we described above. Sometimes several C++ classes are linked to one window class name. All the dockable bars (CExtControlBar, CExtToolControlBar, CExtMenuControlBar, CExtPanelControlBar) are using the same "ProfUIS-ControlBar" window class name string. All the dockable windows have the same properties and window behavior. That is why we have used one window class name. The "ProfUIS-ScrollItemWindow" window class name string is used for all the grid controls (CExtGridWnd, CExtTreeGridWnd, CExtPropertyGridWnd, CExtReportGridWnd).

3) This class may not be designed for subclassing at all. For instance, the CExtScrollWnd class is the basic implementation of a scrollable window. It can be considered as a simplified version of the MFC’s CScrollView view class. The CExtScrollWnd class is designed to be a base class of all the scrollable controls in Prof-UIS including all the grids listed in the item 2, the CExtImageEditWnd image editor control, the CExtColorPaletteWnd color palette picker and the CExtToolBoxWnd control which implements a toolbox window like that in Visual Studio .NET and Visual Studio 2005.

So, we do not recommend you to use the CExtScrollWnd class for any purposes but writing your own scrollable control.

thanks for the clues. but i tried to use a CExtScrollWnd derived object as a custom control but i get a assertion error and i don’t have any clues :s i tried with another object and it’s working like a charm :< do you have any sample code ? i uploaded my code, that’d be really great if you can have a quick look www.pascalorama.info/brol/testcustomcontrol.zip

thanks in advance

We modified the source code of the CMemoryViewerPanel::RegisterChildViewWndClass() method in your project:

LPCTSTR CMemoryViewerPanel::RegisterChildViewWndClass()
{
WNDCLASS _wndClassInfo;
HINSTANCE hInst = ::AfxGetInstanceHandle();
    if( ! ::GetClassInfo(
            hInst,
            MemoryViewerPanel_CLASSNAME,
            &_wndClassInfo
            )
        )
    {
        _wndClassInfo.style = CS_GLOBALCLASS|CS_DBLCLKS|CS_HREDRAW|CS_VREDRAW;
        _wndClassInfo.lpfnWndProc = ::DefWindowProc;
        _wndClassInfo.cbClsExtra = _wndClassInfo.cbWndExtra = 0;
        _wndClassInfo.hInstance = hInst;
        _wndClassInfo.hIcon = NULL;
        _wndClassInfo.hCursor = ::LoadCursor( NULL, IDC_ARROW );
        ASSERT( _wndClassInfo.hCursor != NULL );
        _wndClassInfo.hbrBackground = NULL; 
        _wndClassInfo.lpszMenuName = NULL;
        _wndClassInfo.lpszClassName = MemoryViewerPanel_CLASSNAME;
        if( ! ::AfxRegisterClass( &_wndClassInfo ) )
        {
            ASSERT( FALSE );
            return NULL;
        }
    }
    return MemoryViewerPanel_CLASSNAME;
}

We also made a change so this method is now called from the CMemoryViewerPanel’s constructor. After that, everything seems to be working fine.