Forum

We use the CExtTabMdiWhidbeyWnd.

We have an issue when we close the latest doc/view. After that, from time to time (I know it sounds ackward) we loose one click...

For example if we click on the title bar and try to move the window, the application is not moving on the desktop (it is not maximized ;-) )

Any clue ?

We use the 2.82 version of the toolkit.

 

We got a call stack...

The issue seems to be that the TabWnd enters in Hover while (I guess) it should be destroying itself... we close our last doc (any type, 3 different type of frames).

This forces a CExtMouseCaptureSink::SetCapture( m_hWnd ) hence our troubles (loosing the first click etc)

What would you suggest?

ProfUIS282nd.dll!CExtTabWnd::OnTabWndMouseTrackingHoverStart(long nHitTest=0xfffffff9) Line 5351 C++

ProfUIS282nd.dll!CExtTMWI<CExtTabWhidbeyWnd>::OnTabWndMouseTrackingHoverStart(long nHitTest=0xfffffff9) Line 1813 C++

ProfUIS282nd.dll!CExtTabWnd::_ProcessMouseMove(unsigned int nFlags=0x00000000, CPoint point={...}) Line 5170 + 0x16 bytes C++

ProfUIS282nd.dll!CExtTabWnd::OnMouseMove(unsigned int nFlags=0x00000000, CPoint point={...}) Line 5305 + 0x1e bytes C++

mfc80d.dll!CWnd::OnWndMsg(unsigned int message=0x00000200, unsigned int wParam=0x00000000, long lParam=0x000c0240, long * pResult=0x0012edf0) Line 2169 C++

mfc80d.dll!CWnd::WindowProc(unsigned int message=0x00000200, unsigned int wParam=0x00000000, long lParam=0x000c0240) Line 1741 + 0x20 bytes C++

> ProfUIS282nd.dll!CExtTabWnd::WindowProc(unsigned int message=0x00000200, unsigned int wParam=0x00000000, long lParam=0x000c0240) Line 2140 C++

ProfUIS282nd.dll!CExtTMWI<CExtTabWhidbeyWnd>::WindowProc(unsigned int message=0x00000200, unsigned int wParam=0x00000000, long lParam=0x000c0240) Line 2217 C++

mfc80d.dll!AfxCallWndProc(CWnd * pWnd=0x04ccefac, HWND__ * hWnd=0x000b0b22, unsigned int nMsg=0x00000200, unsigned int wParam=0x00000000, long lParam=0x000c0240) Line 240 + 0x1c bytes C++

mfc80d.dll!AfxWndProc(HWND__ * hWnd=0x000b0b22, unsigned int nMsg=0x00000200, unsigned int wParam=0x00000000, long lParam=0x000c0240) Line 389 C++

mfc80d.dll!AfxWndProcBase(HWND__ * hWnd=0x000b0b22, unsigned int nMsg=0x00000200, unsigned int wParam=0x00000000, long lParam=0x000c0240) Line 411 + 0x15 bytes C++

user32.dll!_InternalCallWinProc@20() + 0x28 bytes

user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes

user32.dll!_DispatchMessageWorker@8() + 0xdc bytes

user32.dll!_DispatchMessageA@4() + 0xf bytes

mfc80d.dll!AfxInternalPumpMessage() Line 183 C++

mfc80d.dll!CWinThread::PumpMessage() Line 896 C++

FRC.exe!FFiREApp::PumpMessage() Line 237 + 0xb bytes C++

mfc80d.dll!CWinThread::Run() Line 625 + 0xd bytes C++

mfc80d.dll!CWinApp::Run() Line 894 C++

mfc80d.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00151f10, int nCmdShow=0x00000005) Line 47 + 0xd bytes C++

FRC.exe!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00151f10, int nCmdShow=0x00000005) Line 33 C++

FRC.exe!__tmainCRTStartup() Line 589 + 0x35 bytes C

FRC.exe!WinMainCRTStartup() Line 414 C

0511a167()

mscorwks.dll!_CallDescrWorker@20() + 0x1f bytes

mscorwks.dll!_CallDescrWorker@20() + 0x1f bytes

FRC.exe!__NULL_IMPORT_DESCRIPTOR() + 0x25e3 bytes Unknown

FRC.exe!__NULL_IMPORT_DESCRIPTOR() + 0x187e8 bytes Unknown

We still cannot reproduce this problem. We would like to ask you to do the following:

1) Find the CExtTMWI::OnTabWndClickedButton() method in the ../Prof-UIS/Include/ExtTabWnd.h file. The class implements MDI tab control’s functionality.

2) Find the following code in this method:

            ::PostMessage(
                  hWndMdiChild,
                  WM_SYSCOMMAND,
                  SC_CLOSE,
                  MAKELONG( point.x, point.y )
                  );

This code closes the active MDI child window when the "X"-button on the right side of the MDI tab control is pressed.

3) Insert the following line immediately before PostMessage() is called:

            ::ReleaseCapture();

We would like to know whether the problem is solved. If not, then please also try to insert the following instead of ReleaseCapture():

SendMessage( WM_CANCELMODE );

The difference between the Whidbey tabs (MDI or simple) and other tabs is only the style of tab items and tab control background. So, if the problem exists, it can be reproduced using any other MDI tabs. We checked our sample applications with MDI tabs (DRAWCLI and ProfStudio) but failed to reproduce the problem. We tried to close the last document using Ctrl+F4, X in the menu bar, X in the MDI tab control, X in a tab item, the Close command in the system menu of MDI child frame window and the Close button in the MDI windows dialog. Would you help us reproduce the problem or send us a test project?

We got a call stack...

 

The issue seems to be that the TabWnd enters in Hover while (I guess) it should be destroying itself... we close our last doc (any type, 3 different type of frames).

 

This forces a CExtMouseCaptureSink::SetCapture( m_hWnd ) hence our troubles (loosing the first click etc)

 

What would you suggest?

 

ProfUIS282nd.dll!CExtTabWnd::OnTabWndMouseTrackingHoverStart(long nHitTest=0xfffffff9) Line 5351 C++



ProfUIS282nd.dll!CExtTMWI<CExtTabWhidbeyWnd>::OnTabWndMouseTrackingHoverStart(long nHitTest=0xfffffff9) Line 1813 C++



ProfUIS282nd.dll!CExtTabWnd::_ProcessMouseMove(unsigned int nFlags=0x00000000, CPoint point={...}) Line 5170 + 0x16 bytes C++



ProfUIS282nd.dll!CExtTabWnd::OnMouseMove(unsigned int nFlags=0x00000000, CPoint point={...}) Line 5305 + 0x1e bytes C++



mfc80d.dll!CWnd::OnWndMsg(unsigned int message=0x00000200, unsigned int wParam=0x00000000, long lParam=0x000c0240, long * pResult=0x0012edf0) Line 2169 C++



mfc80d.dll!CWnd::WindowProc(unsigned int message=0x00000200, unsigned int wParam=0x00000000, long lParam=0x000c0240) Line 1741 + 0x20 bytes C++



> ProfUIS282nd.dll!CExtTabWnd::WindowProc(unsigned int message=0x00000200, unsigned int wParam=0x00000000, long lParam=0x000c0240) Line 2140 C++



ProfUIS282nd.dll!CExtTMWI<CExtTabWhidbeyWnd>::WindowProc(unsigned int message=0x00000200, unsigned int wParam=0x00000000, long lParam=0x000c0240) Line 2217 C++



mfc80d.dll!AfxCallWndProc(CWnd * pWnd=0x04ccefac, HWND__ * hWnd=0x000b0b22, unsigned int nMsg=0x00000200, unsigned int wParam=0x00000000, long lParam=0x000c0240) Line 240 + 0x1c bytes C++



mfc80d.dll!AfxWndProc(HWND__ * hWnd=0x000b0b22, unsigned int nMsg=0x00000200, unsigned int wParam=0x00000000, long lParam=0x000c0240) Line 389 C++



mfc80d.dll!AfxWndProcBase(HWND__ * hWnd=0x000b0b22, unsigned int nMsg=0x00000200, unsigned int wParam=0x00000000, long lParam=0x000c0240) Line 411 + 0x15 bytes C++



user32.dll!_InternalCallWinProc@20() + 0x28 bytes



user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes



user32.dll!_DispatchMessageWorker@8() + 0xdc bytes



user32.dll!_DispatchMessageA@4() + 0xf bytes



mfc80d.dll!AfxInternalPumpMessage() Line 183 C++



mfc80d.dll!CWinThread::PumpMessage() Line 896 C++



FRC.exe!FFiREApp::PumpMessage() Line 237 + 0xb bytes C++



mfc80d.dll!CWinThread::Run() Line 625 + 0xd bytes C++



mfc80d.dll!CWinApp::Run() Line 894 C++



mfc80d.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00151f10, int nCmdShow=0x00000005) Line 47 + 0xd bytes C++



FRC.exe!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00151f10, int nCmdShow=0x00000005) Line 33 C++



FRC.exe!__tmainCRTStartup() Line 589 + 0x35 bytes C



FRC.exe!WinMainCRTStartup() Line 414 C



0511a167()



mscorwks.dll!_CallDescrWorker@20() + 0x1f bytes



mscorwks.dll!_CallDescrWorker@20() + 0x1f bytes



FRC.exe!__NULL_IMPORT_DESCRIPTOR() + 0x25e3 bytes Unknown



FRC.exe!__NULL_IMPORT_DESCRIPTOR() + 0x187e8 bytes Unknown

We still cannot reproduce this problem. We would like to ask you to do the following:

1) Find the CExtTMWI::OnTabWndClickedButton() method in the ../Prof-UIS/Include/ExtTabWnd.h file. The class implements MDI tab control’s functionality.

2) Find the following code in this method:

            ::PostMessage(
                  hWndMdiChild,
                  WM_SYSCOMMAND,
                  SC_CLOSE,
                  MAKELONG( point.x, point.y )
                  );

This code closes the active MDI child window when the "X"-button on the right side of the MDI tab control is pressed.

3) Insert the following line immediately before PostMessage() is called:

            ::ReleaseCapture();

We would like to know whether the problem is solved. If not, then please also try to insert the following instead of ReleaseCapture():

SendMessage( WM_CANCELMODE );

Hard to build a sample solution where we can reproduce the issue.

We have that issue only with the TabMdi |X| button (close all, Ctrl+F4, etc work fine).

But not always!

If we click on the cross and move the mouse it works fine.

If we click on the cross but don’t move the mouse during few seconds (3 is enough) we jump to that weird state.

We still cannot reproduce this problem. We would like to ask you to do the following:

1) Find the CExtTMWI::OnTabWndClickedButton() method in the ../Prof-UIS/Include/ExtTabWnd.h file. The class implements MDI tab control’s functionality.

2) Find the following code in this method:

            ::PostMessage(
                  hWndMdiChild,
                  WM_SYSCOMMAND,
                  SC_CLOSE,
                  MAKELONG( point.x, point.y )
                  );

This code closes the active MDI child window when the "X"-button on the right side of the MDI tab control is pressed.

3) Insert the following line immediately before PostMessage() is called:

            ::ReleaseCapture();

We would like to know whether the problem is solved. If not, then please also try to insert the following instead of ReleaseCapture():

SendMessage( WM_CANCELMODE );

Using Spy++, it seems that the application stops receiving any SetCursor msg or the MessagePump stops working.

If we press on Alt Key + expand a menu -> application is responsive

If we just press on Alt key -> still in a bad state...

Any idea?