Forum

After rebuilding my application with version 253, switching between MDI child windows is unacceptably slow. When child windows are maximised, the redrawing is preceded by drawing in the normal state before maximisation. Your MDIDOCVIEW example has exactly the same problem.

For both the MDIDOCVIEW sample and my application, inactive child windows are also not drawn correctly when the active child is changed from maximised to normal.

The overrides of OnNCPaint() and OnWindowPosChanged() have no effect.

I need some way to suppress the display of an MDI child until its drawing is complete, as well as to ensure that its drawing is as efficient as possible.

Any suggestions will be much appreciated.

Thanks,

Roger Taplin

I was going to send a message to the forum about this issue, but since there is already this one, I will continue the thread.

I noted the same problem with v2.53; actually, in my opinion, the MDI flickering problem (due to an XP bug and not to Prof-UIS) was not totally solved even in the previous versions: in fact in some cases I got some flickering and also in some cases when restoring a maximized MDI child, the NC areas of the other child windows where not repainted correctly due to the code in OnNCPaint() and OnWindowPosChanged().

This is how I fixed the problem in my application. It seems to work very well to me, but I am not sure it may create other problems or it can solve all the problems reported by Roger.

1) Remove the overrides of OnNCPaint() and OnWindowPosChanged() from any MDI child windows (if you are using dynamic bars, you need to modify the CExtDynamicMDIChildWnd::WindowProc to remove WM_NCPAINT and WM_WINDOWPOSCHANGED handling or derive your own class from CExtDynamicMDIChildWnd and override WindowProc ).

2) Add the following class:

class CExtMDIClient : public CWnd {
protected:
    virtual LRESULT WindowProc(UINT message,WPARAM wParam,LPARAM lParam) {
        if (message==WM_MDICREATE) {
            HWND hWndChild;
            LPMDICREATESTRUCT lpMDICreateStruct = (LPMDICREATESTRUCT) lParam;
            
            BOOL bMaximizeNewChild = (WS_MAXIMIZE == (lpMDICreateStruct->style & WS_MAXIMIZE));
            if (!bMaximizeNewChild) {
                // If WS_MAXIMIZE wasn’t requested, check if the currently
                // active MDI child (if there is one) is maximized. If so,
                // maximize the new child window to match.
                SendMessage(WM_MDIGETACTIVE, 0, (LPARAM)&bMaximizeNewChild);
            }

            if (bMaximizeNewChild) {
                SetRedraw(FALSE);
                // We’ll ShowWindow(SW_SHOWMAXIMIZED) instead of using
                // WS_MAXIMIZE (which would cause visual anomolies in some cases)
                lpMDICreateStruct->style &= (~WS_MAXIMIZE);
            }

            hWndChild = (HWND)__super::WindowProc(message,wParam,lParam);

            if (bMaximizeNewChild) {
                ::ShowWindow(hWndChild, SW_SHOWMAXIMIZED);
                SetRedraw();
                RedrawWindow( NULL, NULL, RDW_INVALIDATE | RDW_ALLCHILDREN);
            }
            return (LRESULT)hWndChild;
        }
        else if (message==WM_MDIACTIVATE) {
            LRESULT nResult = 0;
            HWND hWndNew = (HWND)wParam;
            BOOL bOldWasMaximized=FALSE;
            HWND hWndOld = (HWND)SendMessage(WM_MDIGETACTIVE,0,(LPARAM)&bOldWasMaximized);
            if (bOldWasMaximized) {
                ASSERT(::IsZoomed(hWndOld));
                SetRedraw(FALSE);
            }

            if (::IsIconic(hWndNew)) {
                //::ShowWindow(hWndNew, SW_RESTORE);
                SendMessage(WM_MDIRESTORE,(WPARAM)hWndNew);
            }
            
            nResult = __super::WindowProc(message,wParam,lParam);

            if (bOldWasMaximized) {
                SetRedraw(TRUE);
                RedrawWindow( NULL, NULL, RDW_INVALIDATE | RDW_ALLCHILDREN);
            }
            return nResult;
        }
        return __super::WindowProc(message,wParam,lParam);
    }
};

static CExtMDIClient m_MDIClientWnd;

3) in your CMainFrame::OnCreate, add:

VERIFY(m_MDIClientWnd.SubclassWindow(m_hWndMDIClient));

--
Hope this helps.

If you start writing text in the combobox and get compleated text from the list box. After that, if you want to get current index of the selected item from the listbox, return value of the GetcurSel is LB_ERROR(-1).

When the text is completed it does not mean that the corresponding item from the list box is selected, because the list box may contain several items matching the text. You need to manually find the appropriate item with the FindString() method.

Correct, but if I confirm completed text with TAB or ENTER key, steal GetCurSel is returning -1.

What is the proper procedure to remove all references to a CExtPropertyStore
in a CExtPropertyGridCtrl before the CExtPropertyStore can be deleted?

Just one question...
What’s the class that implement your beautiful multicolumn combo box?

Thanks, Paolo

Sorry to disturb you..

Can you provide any sample on how to use CExtComboBoxBase or CExtComboBoxFilterPopupListBox?

Thanks. Paolo

We just added a new FAQ How to enable and use the multicolumn pop-up list box in the CExtComboBox control?, which also includes a sample project.

Thank you for your answer..

How can I make the list box resizable?

Thanks, Paolo.

Dear Support!

I’m trying to disable one of my menu-entries that has a submenu, so it is of type TYPE_POPUP. I understood from some previous thread that I need to disable all entries in that submenu as well before I could disable their "parent". So I put in the UpdateUI handlers of these submenu entries:

pCmdUI->Enable(bSomeCondition);

and in the handler of message CExtPopupMenuWnd::g_nMsgPrepareOneMenuLevel I put the following:

CExtPopupMenuWnd::MsgPrepareMenuData_t *pData =
reinterpret_cast<CExtPopupMenuWnd::MsgPrepareMenuData_t *>( wParam );
ASSERT( pData != NULL );
CExtPopupMenuWnd *pPopup = pData->m_pPopup;
ASSERT( pPopup != NULL );

CExtPopupMenuWnd *pSubPopup;
for (int i = 0; i < pPopup->ItemGetCount(); i++) {
pSubPopup = pPopup->ItemGetPopup(i);
if ( pSubPopup != NULL && pSubPopup->ItemFindPosForCmdID(ID_OF_ONE_SUBMENU_ENTRY) >= 0 )
pPopup->ItemEnabledSet(i, bSomeCondition);
}

In debug mode I can see the ItemEnabledSet is called with the parameters I need, still this "parent" is not disabled, even though all the submenu-entries are. Could you please advise?

I’m using v2.52 with VS2003.

Thank you:
Chris.

A pop-up submenu item becomes disabled automatically if the entire sub tree is disabled. Please check your CExtPopupMenuWnd::g_nMsgPrepareOneMenuLevel registered message handler has the following code at the beginning of the method:

CExtPopupMenuWnd::MsgPrepareMenuData_t * pData =
        reinterpret_cast
        < CExtPopupMenuWnd::MsgPrepareMenuData_t * >
        ( wParam );
    ASSERT( pData != NULL );
CExtPopupMenuWnd * pPopup = pData->m_pPopup;
    ASSERT( pPopup != NULL );
    pData->m_bMenuChanged = true;

It did not help:( At the end of my message handler I return 0; as LRESULT...Could that have any connection to this? I even tried to return 1; still no luck.

One more thing popped to my mind... those submenu entries are all commands to ControlBars, so their updater message handlers go like this:

MessageMap:
ON_UPDATE_COMMAND_UI_RANGE(ID_OF_FIRST_SUBENTRY, ID_OF_LAST_SUBENTRY, OnUpdateControlBarMenu)

Handler definition:
void CMainFrame::OnUpdateControlBarMenu(CCmdUI* pCmdUI)
{
if (!(pCmdUI->m_nID < ID_OF_FIRST_SUBENTRY || pCmdUI->m_nID > ID_OF_LAST_SUBENTRY || bSomeCondition))
pCmdUI->Enable(false);
else
CExtControlBar::DoFrameBarCheckUpdate( this, pCmdUI, false );
}

Any other suggestions? Thank you: Chris.

As we said in the previous message, a popup sub menu item will be always enabled if at least one menu command is enabled in the menu sub tree. So, do not try to disable the popup sub menu item -- just disable all the commands in the sub menu instead. Simply change you control bar command updating method depending on some condition and disable all the control bar commands.

The CExtTabPageContainerWnd sets the focus to the new page in OnTabWndSelectionChange(). This is in general useful and needed, but if the program is not the foreground application and the page selection is automatically changed (not by the user, but by the program itself), the result is stealing the focus to the foreground application.
I think this can be fixed ExtTabPageContainerWnd.h by replacing

::SetFocus( hWndNew );

with

if (::GetFocus()) // only if the focus is in one of the calling thread windows
::SetFocus( hWndNew );

Please let me know what do you think.

If I just fire up my application, close all windows and right mouse click inside the MDI frame I’m getting a wierd disabled popup. I’m not doing any rmouse handling at all inside the mainframe so there is most definitely something wrong happening.

I get a "CExtCustomizeSite::g_nMsgQueryCustomizeSite" then a "CExtControlBar::g_nMsgConstructPopupMenu"

I’ll search around and see if I can’t spot something obvious.

You can customize this built-in Prof-UIS popup menu or even turn it off at all. This is described in the FAQ How to modify or suppress entirely built-in pop-up menus available in Prof-UIS?.

How do I recieve notification when a user selects a tab of a CExtTabPageContainerOneNoteWnd control?

Dear Support,
First, I would like to express my hones appreciation for the great work that you have done with this library!
It will save me lot of money and time, and I can assure you that I will use the Prof-UIS full version as long as I program VC++ :)

I have reading your post on the general form on Aug 1, 2005 with Subject: Re:Getting started and other questions

I have created a SDI application, and tried both ways of implementing the CExtPageNavigatorWnd.
The program starts, but in the moment when I click in the menu on the ID_VIEW_DOCUMENT_NAVIGATOR item, I get an assertion in the following code portion of the aˆ?objcore.cppaˆ?:

void AFXAPI AfxAssertValidObject(const CObject* pOb,
    LPCSTR lpszFileName, int nLine)
{
    if (pOb == NULL)
    {
TRACE(traceAppMsg, 0, "ASSERT_VALID fails with NULL pointer.\n");
-->        if (AfxAssertFailedLine(lpszFileName, nLine))
            AfxDebugBreak();
        return; // quick escape
    }
.
.
.

That means in the AfxAssertFailedLine, with lpszFileName = ..\Src\ExtControlBar.cpp

Please help me fixing what I am doing wrong.
Thanks.
With best regards,
Nedim.

I have sent it on support@prof-uis.com
Thanks!

Hi !
I can send you the whole project, but on which e-mail adress ?

We received your e-mail and fixed your project. But unfortunately two attempts to send this modified project to you have failed -- it seems you server does not accept any attachments. Would you let us know another e-mail address so we can send the project?

Thank you!
I knew that I am going to have some kind of support for the full version of Prof-UIS, but I have never thought that I will have such great help from your side !!!!
With best regards,
Nedim.

If I take a CExtControlBar and float it over my application all of the idle processing time is taken by the framework. I’m not sure what it is doing but I’ve tried it with the following flags set:

CExtControlBar::g_bEnableOnIdleCalls = true;
CExtGridWnd::g_bEnableOnIdleCalls = true;
CExtPopupBaseWnd::g_bEnableOnIdleCalls = true;
CExtTabWnd::g_bEnableOnIdleCalls = true;

and it does not make any difference. Is there anything I can do to stop this?

There is a g_bEnableOnIdleCalls static member included into classes which perform their own message loop. This flag indicates whether the idle time processing should be done by these message loops. The flag is used like as follows:

    if( ?????????????::g_bEnableOnIdleCalls )
    {
        for( LONG nIdleCounter = 0L;
             ::AfxGetThread()->OnIdle( nIdleCounter );
             nIdleCounter ++
             );
    }

Well... after further investigation I am not sure that it has to do directly with the idle processing loop with profuis. With this in mind a took another look at profstudio and noticed that as soon as I undock and of the control windows (Output for example) the program start eating processor time. That is, when all control bars are docked and nothing else is going on (i.e no mouse moving or anything) produis shows 0 percent in the task manager. The minute any windows are undocked and the program is left to idle profstudio shows anywhere between 5 and about 14 percent in the task manager. This might be the root of our problem if the undocked windows are eating idle time or message or something else.

Hi,
I’ve just built the ActiveScripts sample app and only the first sample script "Type your VB script here" is working. All others raise a script error when AutoWindow is used. eg.
Set commands = AutoWindow.Commands ’the single collection of commands

Neville Franks

Please make sure you have registered the type library of the Prof-UIS Automation Pack by invoking the following from the command line:

regsvr32 ProfAuto25?????.DLL

Dear Support,
I am using VS 2005, and I have run the Integration Wizard once again to register the Help, but there is no Prof-UIS Help appearing in the MSDN Contents tab.
Sorry that I have to bother you and take your time.
I have pressed F1 on CExtPageNavigatorWnd in the code, and I get a help in MSDN, but if i go and type CExtPageNavigatorWnd in the Search, it finds nothing. So how do I really use it, just with pressing F1 in code, or there is a way to Browse all Chapters and find keywords in the Search option of the MSDN?
Thanks,
Nedim.

First of all, please make sure that (no filter) is selected in the Filtered by: combo box in the Content dockable window. This will allow you to see all the namespaces registered in the VS Combined Collection including Prof-UIS. If the problem persists, please contact us again.

Hi all !
Is it possible to change the height of the CExtStatusControlBar, so that I can put some custom height controls in the status bar?
Thanks!
With best regards,
Nedim.

I have a Grid that contains two columns the first is a combobox with the following code in the OnClick override:
bool CBaseComboCell::OnClick(
        CExtGridWnd & wndGrid,
        const CExtGridHitTestInfo & htInfo,
        UINT nChar,
        UINT nRepCnt,
        UINT nFlags
        )
    {
        ASSERT_VALID( this );
        ASSERT_VALID( (&wndGrid) );
        ASSERT( ! htInfo.IsHoverEmpty() );
        ASSERT( htInfo.IsValidRect() );
        ASSERT( nChar == VK_LBUTTON || nChar == VK_RBUTTON || nChar == VK_MBUTTON );
        ASSERT( 0 <= nRepCnt && nRepCnt <= 3 );
        if( nChar == VK_LBUTTON && ( nRepCnt == 1 || nRepCnt == 2 ) )
        {
            if( (nFlags&(MK_SHIFT|MK_CONTROL)) == 0 )
            {
                CExtGridHitTestInfo htInfoTrack( htInfo );
                htInfoTrack.m_dwAreaFlags |= __EGBWA_CELL_BUTTON;
                htInfoTrack.m_nButtonType = (int)__EBTT_DROPDOWN;
                return
                    wndGrid.OnGridTrackCellButton(
                        this,
                        htInfoTrack
                        );
            }
        }
        return
            CExtGridCellComboBox::OnClick(
                wndGrid,
                htInfo,
                nChar,
                nRepCnt,
                nFlags
                );
    }

In the grid I have overridden the OnGridCellInputComplete method and am testing if the user has selected something from the first column combobox and if so automatically editing the second column with this->EditCell(1L,nRowNo);
My problem is that it goes into editing the second column ok but the combo is still in the dropped down state and does not redraw.

Thanks in advance,
Eddie

Please insert the following lines before you begin editing a cell:

 if( CExtPopupMenuWnd::IsMenuTracking() )
  CExtPopupMenuWnd::CancelMenuTracking();

Hi

i had an ASSERTION Problem on CExtControlBar::ProfileBarStateLoad.
Finally i found the problem. While the program is inside the CMainFrame::OnCreate if you have any ON_UPDATE_COMMAND_UI(...) they called.If inside it you call any function that checks windows especially if you call any GetRuntimeClass, you get the ASSERTION.
I finally put a BOOL variable _isInsideOnCreate which goes FALSE on exit from OnCreate that controls all the ON_UPDATE_COMMAND_UI.

regards

George

Is there a way to get the image ID of a toolbar button ? I mean, as it happens with a standard MFC CToolbarCtrl control, I would like to change image of a CExtToolControlBar button by changing the ID of the button’s image. Is it possibile ?
Thanks

If I set a CExtComboBox to be of type "Simple" then it does not draw correctly. It appears to try to draw as a "Drop List" style. Is the simple style not implemented or am I missing something? If I try to use a standard CComboBox then it flickers on dialog resizing and also the bottom of the list is not drawn correctly and jumps on resizing. Switching "No Integral Height" to False helps with the jumping, but the bottom of the frame is still drawn incorrectly.

Thanks

Comparing the CExtComboBox with the VC2003 similar control, in my opinion the CExtComboBox drop button is a bit uglier.
If you look at this screenshot you can see the difference is that the prof-uis button is a bit larger and the arrow not exactly centered. I do not know if this is a drawing problem in my system due to some settings or if it is normal. Please let me know.

Hello,

In compiling Profuis-Skin library, link error raised : LibPNGDLLCRT.lib can not be found.

I’m going to mimic your pluggable sample.
That’s too hard!!!

I’m not a genius. It’s difficult to understand everything through sample codes.

Do you have any plan to publish some reference manual?

Best regards,

jb.

When dragging and dropping a toolbar to a new location, the other toolbars move around.

Is there a way to make the other toolbars stay put until the dragged toolbar is dropped in its new location?

Thanks.

Any Prof-UIS toolbar window (CExtToolControlBar) is able to stick to its desired position. We call this feature "persistent affixment behavior". When you start redocking a toolbar, this affects all other toolbars but they are "trying" to remain at their desired positions as much as possible. The last drag-and-droped toolbar takes precedence over other toolbars and has better chances to be closer to its desired position than other toolbars. This behavior is similar to that in MS Office 2000 / XP / 2003 and Visual Studio .NET / 2005. We think this is the best toolbar behavior ever implemented in any known application. So, we have no idea how to restrict the current algorithm. Any restriction would certainly make the toolbar less user-friendly. Please also note that you can also hold down the CTRL key, to prevent the toolbar from immediate docking. Please let us know your point of view.

Test users report that they just cannot get the toolbar to where they want them to be. They describe it as ’finicky’.

As soon as you drag a toolbar just a little the other toolbars start re-arranging themeselves in what appears a rather random fashion.
A lot of flickering is also caused by the random adding and removing of additional toolbar rows.
Taking the ProfStudio example, I have toolbars arranged as follows:

Web | Debug | Build
Standard | Text Editor

Grab the Debug bar and move the mouse slowly downwards

First you get a third row inserted. Moving down further you get the empty row moved to the bottom and the dragged toolbar ends up all the way to the right far away from the mouse cursor. It takes very careful manouvering to insert the Debug bar between the Standard and Text Editor bars.
I can provide screen shots if you need them.

When observing MS Office, I notice that the reaction to movement seems much slower, less ’violent’. You have to drag farther and and hover a bit before the other toolbars
are re-arranged.

Ideal I thing would be a mode (which can be set permanenly as a property), that allows dragging and dropping just as if CTRL is pressed but docks the toolbar in its dropped location when the left mouse button is released.

Thanks.

Thank you for your feedback. We reproduced the behavior you described (closed all the control bars in ProfStudio and created the same layout of toolbars in ProfStudio and in Microsoft Word). We confirm that when you have this very layout and you are dragging a toolbar (which is located on the right side) downwards, that causes that the dragged toolbar may appear both on the left side and on the right side of the toolbar initially located under the toolbar being docked. We will fix it. Thank you for this report.

However, the behavior you want to see is not standard (here we imply the behavior pertinent to Microsoft products). Of course, we can implement such an option (there is almost nothing impossible) but it requires some time and we have a list of new features our customers are waiting for. Anyway, if it is important to you, we will add this to our to-do list.

Cool, thanks. Any chance of slowing it down a bit like in MS Office? I have encountered this myself quite often.

What I do to take the immediate reaction out of something like this is that on WM_MOUSEMOVE I set off a timer.
When the timer is triggered I check if the mouse position is still within 6 pixels of the original mouse message.
If not, do nothing.
If another WM_MOUSEMOVE comes in I reset any existing timer.

That way you only react to mouse moves when the user hovers the mouse cursor ’waiting’ for the reaction.

I am not trying to tell you how to do things, just trying to help.

Thanks.