Forum

I did recompile my application with prof-uis 2.83 support (full license) and now all the CExtResizableDialogs, including a CExtTabWnd control, fail during the Create() method. If I recompile the same code with prof-uis 2.60 support everything works. Actually I’m compiling with debug MBCS support , compiler VisualStudio 2005 or VisualStudio 2008.

Please insert the following lines into the .rc2 file in your project:

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

#if (!defined PROF_UIS_X64) && (!defined PROF_UIS_IA64) && (!defined PROF_UIS_FORCE_NO_MANIFEST)
            1 24 DISCARDABLE "res\\manifest_x86.xml"
#endif

The XML manifest files can be found in the res subfolder in any of Prof-UIS sample applications. You can copy them into the res subfolder of your project.

Hello.

I want to do the following drawing by Vista.

Because I am troubled, please teach it

Give my best regards

You should handle a WM_NCPAINT message. Painting on the non-client area in Windows Vista is same as in Windows XP. The difference is that Vista prepares a glass background and you are painting some content over it when in XP you yourself should draw a background. By default, painting over glass like window non-client area is disabled for all the windows running on Vista desktop. To enable non-client area access you should invoke the following code:

bool bDwmMode = g_PaintManager.m_DWM.IsCompositionEnabled() ? true : false;
            if( ! bDwmMode )
                        return . . . // we are not running on Vista or display mode is not 32-bit or DWM glass is disabled in desktop settings
HWND hWnd = . . .
CExtDWM::__EXT_DWMNCRENDERINGPOLICY ncrp = CExtDWM::__EXT_DWMNCRP_ENABLED;
HRESULT hr = g_PaintManager.m_DWM.DwmSetWindowAttribute( hWnd, CExtDWM::__EXT_DWMWA_NCRENDERING_POLICY, &ncrp, sizeof(ncrp) );
BOOL bAllow = TRUE;
            hr = g_PaintManager.m_DWM.DwmSetWindowAttribute( hWnd, CExtDWM::__EXT_DWMWA_ALLOW_NCPAINT, &bAllow, sizeof(bAllow) );
            hr;

After that, the hWnd window starts receiving the WM_NCPAINT messages and you can paint what you need. Your WM_NCPAINT message handler also should use the g_PaintManager.m_DWM.IsCompositionEnabled() code for detecting Vista glass painting mode.

Hello.

A triangle is not drawn.

Backgrounds are always displayed with white.

Could you send us this test project?

// ----------------------------------------------------------------------------

/**

 *  @brief   

 */

// ----------------------------------------------------------------------------

void CMuResizableDialog::OnSupportVista()

{

 bool bDwmMode = g_PaintManager.m_DWM.IsCompositionEnabled() ? true : false;

    if( ! bDwmMode ){

  return ;

 }

 HWND hWnd = m_hWnd;

 CExtDWM::__EXT_DWMNCRENDERINGPOLICY ncrp = CExtDWM::__EXT_DWMNCRP_ENABLED;

 HRESULT hr =

  g_PaintManager.m_DWM.DwmSetWindowAttribute(

   hWnd,

   CExtDWM::__EXT_DWMWA_NCRENDERING_POLICY,

   &ncrp, sizeof(ncrp)

  );

 BOOL bAllow = TRUE;

    hr = g_PaintManager.m_DWM.DwmSetWindowAttribute(

     hWnd, CExtDWM::__EXT_DWMWA_ALLOW_NCPAINT,

     &bAllow, sizeof(bAllow)

    );

    hr;

}

// ----------------------------------------------------------------------------

/**

 *  @brief   

 */

// ----------------------------------------------------------------------------

BOOL CMuResizableDialog::OnInitDialog()

{

    VERIFY( CExtResizableDialog ::OnInitDialog() );

 OnSupportVista();

    :

    :

    :

}

// ----------------------------------------------------------------------------

/**

 *  @brief    

 */

// ----------------------------------------------------------------------------

void CMuResizableDialog::OnNcPaint()

{

    CExtResizableDialog::OnNcPaint();

    ERPaint ( TRUE );

}

// ----------------------------------------------------------------------------

/**

 *  @brief   

 *  @param   

 */

// ----------------------------------------------------------------------------

void CMuResizableDialog::ERPaint( BOOL blActive )

{

    if ( m_blERBtnFlag == FALSE )

        return;

    ERSize();

    CDC    * pCDC;

    pCDC = this->GetWindowDC();

    CBrush brush;

   if ( m_blERHover == TRUE || blActive == FALSE ){

        brush.CreateSolidBrush( GetSysColor( COLOR_BTNFACE ) );

        pCDC->FillRect( &m_ERBtnRect , &brush );

        brush.DeleteObject();

    }else{

        brush.CreateSolidBrush( GetSysColor( COLOR_BTNFACE ) );

        pCDC->FillRect( &m_ERBtnRect , &brush );

        brush.DeleteObject();

    }

    CPen _pen;

    _pen.CreatePen( PS_SOLID , 1 , GetSysColor(COLOR_BTNHILIGHT) );

    CPen * pOldPen = pCDC->SelectObject( &_pen );

    pCDC->MoveTo( m_ERBtnRect.left , m_ERBtnRect.top );

    pCDC->LineTo( m_ERBtnRect.right, m_ERBtnRect.top );

    pCDC->MoveTo( m_ERBtnRect.left , m_ERBtnRect.top );

    pCDC->LineTo( m_ERBtnRect.left , m_ERBtnRect.bottom );

    _pen.DeleteObject();

    _pen.CreatePen( PS_SOLID , 1 , GetSysColor(COLOR_BTNSHADOW ) );

    pCDC->SelectObject( &_pen );

    pCDC->MoveTo( m_ERBtnRect.right    , m_ERBtnRect.bottom  );

    pCDC->LineTo( m_ERBtnRect.right    , m_ERBtnRect.top - 1 );

    pCDC->MoveTo( m_ERBtnRect.right    , m_ERBtnRect.bottom  );

    pCDC->LineTo( m_ERBtnRect.left - 1 , m_ERBtnRect.bottom  );

    pCDC->SelectObject( pOldPen );

    //--------------------------------------

    //

    int      ArrowCnt;

    int      iRec;

    CRgn     RgnArrow;

    POINT    ArrowPnt[100];

    int     iSpace = 2;

    if ( m_blERBtnWayFlag == FALSE ){

        //-------------------------------------------

        // 縮小矢印

        ArrowCnt = 3;

        ArrowPnt[0].x = iSpace;

        ArrowPnt[0].y = m_BtnSize - iSpace;

        ArrowPnt[1].x = m_BtnSize - iSpace;

        ArrowPnt[1].y = m_BtnSize - iSpace;

        ArrowPnt[2].x = m_BtnSize / 2;

        ArrowPnt[2].y = iSpace;

    }else{

        //-------------------------------------------

        // 拡大矢印

        ArrowCnt = 3;

        ArrowPnt[0].x = iSpace;

        ArrowPnt[0].y = iSpace;

        ArrowPnt[1].x = m_BtnSize - iSpace ;

        ArrowPnt[1].y = iSpace;

        ArrowPnt[2].x = m_BtnSize / 2;

        ArrowPnt[2].y = m_BtnSize - iSpace;

    }

    for ( iRec = 0 ; iRec < ArrowCnt ; iRec++){

        ArrowPnt[iRec].x = ArrowPnt[iRec].x + m_ERBtnRect.left;

        ArrowPnt[iRec].y = ArrowPnt[iRec].y + m_ERBtnRect.top;

    }

    if ( blActive == TRUE ){

        if ( m_blERHover == TRUE ){

            //brush.CreateSolidBrush( GetSysColor(COLOR_INACTIVECAPTION ) );

            brush.CreateSolidBrush( GetSysColor(COLOR_ACTIVECAPTION ) );

        }else{

            brush.CreateSolidBrush( GetSysColor(COLOR_ACTIVECAPTION ) );

        }

    }else{

        brush.CreateSolidBrush( GetSysColor(COLOR_BTNSHADOW ) );

    }

    VERIFY ( RgnArrow.CreatePolygonRgn( ArrowPnt , ArrowCnt , ALTERNATE ) );

    pCDC->FillRgn( &RgnArrow , &brush );

    brush.DeleteObject();

    this->ReleaseDC( pCDC );

}

I created a MFC project using some Prof-UIS controls (CExtPropertyGridCtrl and CExtControlBar). The application was working fine until I changed the struct member alignment to 1-byte. I need this struct alignment for our DSP functions to work. Is there any way to get the controls to work with the 1-byte struct alignment setting?

Thanks,

Paul

Hello.

http://www.prof-uis.com/prof-uis/tech-support/support-forum/cextribbonbar-question-63503.aspx

1) We are not sure that this is the bug because we don’t know how to reproduce it.

2) It is the same situation and nobody reported about menu hanging problems yet.

It looks like you have some special software used on your computer which injects DLL hooks into all the processes and affects to both problems. Please let us know whether you can reproduce these issues more than on one computer?

Hello

>1) We are not sure that this is the bug because we don’t know how to reproduce it.

 Malfunction reappears when I make a UI theme "native Window xp".

At the time of "office2007 theme", the ribbon works normally.

our app tries to create a toolbar based on templates defined in a dll, when it calls

g_CmdManager->UpdateFromToolBar(...)

UpdateFromToolBar fails as it doesn’t know inside which module it should look for the resource. Is there any way to let command manager or resource manager know inside which module it should search for the resource ?

Thanks

Yes, there is a solution, but it’s related to Prof-UIS toolbars (CExtToolControlBar) and for other Prof-UIS components only. All the Prof-UIS classes are loading resources using the Prof-UIS resource manager component (the CExtResourceManager class and the g_ResourceManager global smart pointer variable). By default, resource manager searches the queried resources using exactly the same algorithm which is coded inside MFC. The first extended feature of the resource manager is the preferred language identifier for loading resources. You can turn on the preferred language identifier for searching available resources using the g_ResourceManager->AllowCustomLang(true); code and then you can specify the desired language identifier using the g_ResourceManager->SetLangIdDesired( __EXT_MFC_LANG_ID_*** ) code. All the supported by Prof-UIS __EXT_MFC_LANG_ID_*** language identifiers are defined in the …/Prof-UIS/Include/ExtCmdManager.h file. After these two invocations, the resource manager will use the resource searching algorithm similar to MFC’s but it will search resources of desired language first, and then, on the second step, it will search resources like MFC does. The third feature of the resource manager, and the most interesting feature for you, is the list of HINSTANCE handles of DLL modules which will be used for searching resources before all the described above details will be applied in the resource searching algorithm. The set of the CExtResourceManager::RscInst_***() methods is related to this feature. You should use the g_ResourceManager->RscInst_Insert( hInstance, bFreeInstance ) code for adding your DLL into resource searching algorithm of the resource manager. The hInstance parameter is the DLL module handle. The bFreeInstance parameter is the flag which indicates whether the resource manager should invoke the ::FreeLibrary( hInstance ); code at shutdown. The handle of the DLL module specified in the invocation of the CExtResourceManager::RscInst_Insert() method can the module handle of any kind of DLL. It can be pure resource DLL, it can be DLL with run-able code which is used or un-used by code of your application, it even can be the module handle of EXE file which was loaded as resource searching target using the ::LoadLibrary() Win32 API.

If your DLL modules are MFC extension DLLs and they are loaded using AfxLoadLibrary() API, then their resources will be found successfully.

This is a bug I reported a long time ago:

1. You have a tree grid control

2. The window the grid is not in focus,.

3. You start dragging one of the column separators to resize a column. (make sure the window of the grid is not in focus when you start dragging the separator)

You get a flicker in the first column (the tree column) as if all the items in this column lost their identation for a second.

Please fix.

We didn’t forget this. We are delayed fixing this issue due to working on improvements of all the Prof-UIS grid classes needed for implementation of the new grid control called formula grid.

How about an answer... I see that I’m not alone with this bug...

Thanks.

I have a dialog, which is a child of a CExtDynamicControlBar.  When I call Create, it fails to load:

    if (!_imDlg.Create(InstantMessageDlg::IDD, _imCB))

    {

        TRACE0("Failed to create instant message window\n");

        return 0;

    }

but if I replace the CRichEditCtrl on the dialog with a CExtEdit control, everything works fine.  Is there some kind of issue with using a rich edit control with a Professional UI dialog?

Thanks,

Scott




 






We had previously reported an issue with the input of key code type character sequences (http://www.prof-uis.com/prof-uis/tech-support/support-forum/prof-control-input-problem-61925.aspx) which you did provide a fix for.  Unfortunately that only appears to fix key codes for the views (and possibly a few other controls) but we are experiencing the same issue with the grid cells.  Currently, there seems to be no support at all for key code entry in the grid cells, no matter what the user types no characters results.

I call GetColor when the user selects a colour.

The following COLORREF should be:

Red: 0x00FF0000

Green: 0x0000FF00

Blue: 0x000000FF

What you get form GetColor is the following:

Red: 0x000000FF

Green: 0x0000FF00

Blue: 0x00FF0000

The red and blue seem to be reversed.

Please confirm if this is a bug or misuse on my part.

Thanks.

I have a dialog with two radio buttons that use the BS_BITMAP attribute.

When they use CButton, they worked fine.  But once I switch to CExtRadioButton, the bitmaps are ignored and they are displayed with text.  Here are the resource entries:

    CONTROL         "Portrait",IDC_ORIENT_PORT,"Button",BS_AUTORADIOBUTTON | BS_BITMAP | BS_CENTER | BS_VCENTER | BS_PUSHLIKE | WS_GROUP | WS_TABSTOP,231,7,16,16

    CONTROL         "Landscape",IDC_ORIENT_LAND,"Button",BS_AUTORADIOBUTTON | BS_BITMAP | BS_CENTER | BS_VCENTER | BS_PUSHLIKE | WS_TABSTOP,250,7,16,16

Here are the code references to them

 DDX_Control(pDX, IDC_ORIENT_LAND, m_btnPrtLand);

 DDX_Control(pDX, IDC_ORIENT_PORT, m_btnPrtPort);

 hBitmap   = ::LoadBitmap(AfxGetApp()->m_hInstance, MAKEINTRESOURCE(IDB_PRT_PORT));

 m_btnPrtPort.SetBitmap(hBitmap);

 hBitmap   = ::LoadBitmap(AfxGetApp()->m_hInstance, MAKEINTRESOURCE(IDB_PRT_LAND));

 m_btnPrtLand.SetBitmap(hBitmap);

Hello.

If width is narrow, character string breaks off.

 

When the display area of the character is small,

I want to display character string from the left

Or

I want to display a tool tip

Hello.

Do not maintenance characteristics improve?

In addition, I think that bugs decrease.

A sample.

I have a CExtGridWnd that is inside a



typedef CExtNCSB < CExtWA < CExtWS < CExtAFV < CFormView > > > > GridFormView;



My problem is when I refresh the grid and the number of columns exceeds the visible region, the horizontal scrollbar does not automatically show up.  If I resize the frame or move a dynamic control bar or resize an adjacent resizeable control bar, then the scrollbar shows up.



What can I do to force the horizontal scrollbar to always display when needed?

Hello.

[Part1]

With the following screens, I call Program-FuncA.

However, PopupMenu is not non-displayed unless FuncA is finished

I want to make a menu non-display

[Part2]

Would the contribution of the following be already revised?

When is the exhibition of the revision?

http://www.prof-uis.com/prof-uis/tech-support/support-forum/bug-in-cextribbon-63275.aspx

Part 1: We need more details about the problem. You are clicking on any command item on some popup menu. It’s closed and handler method is invoked, right? What’s wrong?

Part 2: We guess we know what’s the problem is described on your screen shot. It can be reproduced on enough slow computer only. The popup menus of ribbon bar are closed using fade out animation effect. If we start to drag-n-drop the main frame window like demonstrated on your screen shot, then the currently opened popup menus are closed with the slow delay or with the very slow fade out animation until we stop drag-n-dropping of the main frame window. We must note, that Word 2007 and Excel 2007 have exactly the same menu behavior. So, we are not sure this is a bug because menus become closed finally.

Hello.

>Part 1: We need more details about the problem. You are clicking on any command item on some popup menu. It’s closed and handler method is invoked, right? What’s wrong?

Will how to use be bad?

class CMainFrame : public CMuMdiFrame

                 , public  CExtDynamicBarSite

{

    //{{AFX_VIRTUAL(CMainFrame)

    public:

    virtual BOOL OnCmdMsg(UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO* pHandlerInfo);

  :

  :

  :

  :

BOOL CMainFrame::OnCmdMsg(UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO* pHandlerInfo)

{

 if ( CNxfWinEngine::OnCmdMsg( nID, nCode, pExtra, pHandlerInfo) == FALSE ){

     return FALSE;

    }

  :

  :

  :

  :

class CNxfWinEngine

{

// ----------------------------------------------------------------------------

//  メンバー

public:

    enum ECID

    {

        ECID_UNKNOW         = 0,    /// Unknow

        ECID_CLICK          = 1,    ///

        ECID_UPDATE_CMDUI   = 2,    ///

    };

    static BOOL OnCmdMsg(UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO* pHandlerInfo);

  :

  :

  :

  :

BOOL CNxfWinEngine::OnCmdMsg(UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO* pHandlerInfo)

{

    CCmdUI * pCmdUI;

    pCmdUI = (CCmdUI *)pExtra;

    if( nCode == CN_COMMAND && pExtra == NULL  ){

        return OnCommands( CNxfWinEngine::ECID_CLICK , nID );

    }

    else if( nCode == CN_UPDATE_COMMAND_UI ){

        return OnCommands( CNxfWinEngine::ECID_UPDATE_CMDUI , nID , pCmdUI );

    }

    return TRUE;

}

BOOL CNxfWinEngine::OnCommands ( ECID eComIDType , UINT nID , CCmdUI * pCmdUI )

{

    switch( nID ){

    // ------------------------------------------------------------------------

    // Ribbon Tab

    // ------------------------------------------------------------------------

    case IDM_RIBBON_TAB_HOME:

        switch ( eComIDType ){

        case ECID_CLICK:

            OnRibbonTabHome();

            break;

        }

        break;

    case IDM_RIBBON_TAB_PANEL:

        switch ( eComIDType ){

        case ECID_CLICK:

            OnRibbonTabPanel();

            break;

        }

        break;

Hello.

>Part 2: We guess we know what’s the problem is described on your screen shot.

>It can be reproduced on enough slow computer only.

>The popup menus of ribbon bar are closed using fade out animation effect.

>If we start to drag-n-drop the main frame window like demonstrated on your screen shot,

>then the currently opened popup menus are closed with the slow delay or with the very slow fade out animation until we stop drag-n-dropping of the main frame window.

>We must note, that Word 2007 and Excel 2007 have exactly the same menu behavior. So, we are not sure this is a bug because menus become closed finally.

 menu does not do fade-out.

 Even if I wait for 10 minutes, the menu is displayed.

 It is displayed forever.

Machine specifications

2.6Ghz

I’m trying to put a toolbar in a resizable dialog.  In the resource I have:

IDD_DOX_LIST DIALOGEX 0, 0, 296, 222

STYLE DS_SETFONT | WS_MAXIMIZEBOX | WS_POPUP | WS_CAPTION | WS_SYSMENU | WS_THICKFRAME

CAPTION "Measurement List"

FONT 8, "MS Sans Serif", 0, 0, 0x1

BEGIN

    CONTROL         "Incr",IDC_BTN_DEC_INCR,"Button",BS_OWNERDRAW | WS_TABSTOP,4,28,16,14

    CONTROL         "Decr",IDC_BTN_DEC_DECR,"Button",BS_OWNERDRAW | WS_TABSTOP,20,28,16,14

    CONTROL         "Print",IDC_BTN_PRINT_DOX,"Button",BS_OWNERDRAW | WS_TABSTOP,42,28,16,14

    COMBOBOX        IDC_CMB_DRAG_LINK,62,28,135,64,CBS_DROPDOWNLIST | WS_TABSTOP,WS_EX_CLIENTEDGE

    CONTROL         "Float",IDC_BTN_FLOAT_DOX,"Button",BS_OWNERDRAW | WS_TABSTOP,239,28,50,14

    GROUPBOX        "",IDC_ST_BTNS,1,23,292,20,WS_DISABLED

    CONTROL         "",IDC_GRID_DOX,"RGuiRoot",WS_CLIPCHILDREN | WS_TABSTOP,1,46,292,162

    CONTROL         "",IDR_DOXLST_BAR,"ProfUIS-ControlBar",WS_DLGFRAME | 0x2034,0,0,294,14

END

and

IDR_DOXLST_BAR TOOLBAR  16, 16

BEGIN

    BUTTON      ID_DOXLST_DEC_INCR

    BUTTON      ID_DOXLST_DEC_DECR

    SEPARATOR

    BUTTON      ID_DOXLST_PRINT

    SEPARATOR

    BUTTON      ID_DOXLST_CMB_DRAG

    SEPARATOR

    BUTTON      ID_DOXLST_FLOAT

END

In OnInitDIalog I have the following:

 CExtNCW<CExtResizableDialog>::OnInitDialog();

 m_wndToolBar.LoadToolBar(IDR_DOXLST_BAR);

 RepositionBars(0, 0xFFFF, IDR_DOXLST_BAR);

RepositionBars is also called in OnSize()

The toolbar appears but it takes up the entire height of the dialog.

ALSO, how do I set the toolbar button status?  Do I just add ON_UPDATE_COMMAND_UI entires to the dialog message map?

I’m guessing on the style flags in the ProfUIS-ControlBar. I just copied it from examples.

CExtToolControlBar windows are always based on the MFC’s command updating mechanism. Yes, you should add command updating methods for toolbar buttons if you want to change enabled/checked/radio states of toolbar buttons. Any MFC/Prof-UIS control bars can be re-dockable only inside frame windows. The control bars created inside dialogs and other non-frame windows always take up some space in their parent window as the status bar does.

I forgot to mention, I added this to the data map:

 DDX_Control(pDX, IDR_DOXLST_BAR, m_wndToolBar);

 

Is there any way to make a CExtButton operate as a "sticky" button?  By that I mean that when clicked it stays down, releasing when it’s clicked a second time.

In the same scenario in my previous bug report, The text of the merged cell is cut-off at the imaginary location of the first cell end (as if it was not joined. even though the text is centered correctly):

Hi,

I have a tree grid with two rows haeder which are supposed to look like this:

+--------------------+
|	 Main Header    |
+------+------+------+
| Sub1 | Sub2 | Sub3 |
+------+------+------+

This is the code I wrote to implement it:

    CExtGridCellHeader* pCellHdr = (CExtGridCellHeader*)GridCellGetOuterAtTop(0, 0, RUNTIME_CLASS(CExtGridCellHeader));
    pCellHdr->TextSet(_T("Main Row Header Tilte"));
    pCellHdr->ExtentSet(300);
    pCellHdr->ModifyStyle(__EGCS_TA_HORZ_CENTER);

    pCellHdr = (CExtGridCellHeader*)GridCellGetOuterAtTop(0, 1, RUNTIME_CLASS(CExtGridCellHeader));
    pCellHdr->TextSet(_T("Sub Title1"));
    pCellHdr->ExtentSet(100);
    pCellHdr->ModifyStyle(__EGCS_TA_HORZ_CENTER);

    pCellHdr = (CExtGridCellHeader*)GridCellGetOuterAtTop(1, 1, RUNTIME_CLASS(CExtGridCellHeader));
    pCellHdr->TextSet(_T("Sub Title2"));
    pCellHdr->ExtentSet(100);
    pCellHdr->ModifyStyle(__EGCS_TA_HORZ_CENTER);

    pCellHdr = (CExtGridCellHeader*)GridCellGetOuterAtTop(2, 1, RUNTIME_CLASS(CExtGridCellHeader));
    pCellHdr->TextSet(_T("Sub Title3"));
    pCellHdr->ExtentSet(100);
    pCellHdr->ModifyStyle(__EGCS_TA_HORZ_CENTER);

    GridCellJoinSet(CSize(3,1), 0, 0, 0 , -1);

But it does not work. This is the screen-shot of how it looks - the mail title only occupied two columns, and not three, event though I specified in the CSize(3,1), and there is another problem, that I can only resize the  columns width from the first column, the other two separators are just ignored... the cursor icon changes, but the dragging is totaly ignored.

Please explain what is wrong, either in my code, or in yours...

Thanks,

Ron.

 

Unfortunately now. But this can be done with the one line of code because the following method of the CExtGridWnd class allows to initialize more than one grid cell at a time if the nColCount and/or nRowCount parameters are greater than 1:

   virtual bool GridCellSet(
                        LONG nColNo,
                        LONG nRowNo,
                        const CExtGridCell * pCell = NULL, // NULL - clear (make empty)
                        LONG nColCount = 1L,
                        LONG nRowCount = 1L,
                        INT nColType = 0, // -1 - nColNo is fixed column at left, 1 - at right, 0 - data cell
                        INT nRowType = 0, // -1 - nRowNo is fixed column at top, 1 - at bottom, 0 - data cell
                        bool bRedraw = true
                        );

The cell joining feature requires non-NULL grid cell inside joined areas. Please initialize additional two CExtGridCellHeader grid cell objects in the top row inside the Main Header area and one more CExtGridCellHeader grid cell object above the Sub Title 3 header cell.

Hi,

there i a bug when your are between maximized CMDIChildWnd. I want to have the MDIChilds always be maximzed. So i have remove WS_MINIMIZEBOX and WS_MAXIMIZEDBOX from the style and add WS_MAXIMIZE. When i add a new document it will be maximized. But when i switch between two windows, all maximized windows will be now overlapped. I reproduced the bug with your sample MDIDOCVIEW. The changes i make:

BOOL CChildFrame::PreCreateWindow(CREATESTRUCT& cs)
{
    if( ! CExtNCW < CMDIChildWnd > :: PreCreateWindow( cs ) )
        return FALSE;
    cs.style =
        WS_CHILD | WS_VISIBLE
            | WS_MAXIMIZE | WS_CAPTION | WS_SYSMENU
            | FWS_ADDTOTITLE | WS_THICKFRAME
//            | WS_MINIMIZEBOX | WS_MAXIMIZEBOX
            | WS_CLIPCHILDREN | WS_CLIPSIBLINGS
            ;
    cs.dwExStyle &= ~(WS_EX_CLIENTEDGE|WS_EX_STATICEDGE|WS_EX_DLGMODALFRAME);
    return TRUE;
}

Why is the style of the windows changed? Please send me a patch to resolve the problem.

Thanks

The way of creating always maximized MDI child frames described in this forum thread does not work in MFC only applications too. We can make such approach working only after complete recoding of MDI interface. We would like to ask you to take a look at the ProfStudio sample application. It implements the always maximized MDI child frames and you can switch to classic MDI and back at run-time.

Yeah would be nice.. I face the same Problem.. when all childs are maximised and i switch to another child it flickers.. 



Let me know when the bugfix is out.



Thanks

We just want to notify you that we reproduced this problem and are working on it. The fix will be available soon.