Professional UI Solutions
Site Map   /  Register
 
 

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » Ctrl-Tab goes the other way round Collapse All
Subject Author Date
Thomas Maurer Apr 7, 2006 - 9:48 AM

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

Technical Support Apr 9, 2006 - 7:57 AM

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.

Thomas Maurer Apr 18, 2006 - 6:38 AM

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

Technical Support Apr 18, 2006 - 7:22 AM

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.

Thomas Maurer Apr 18, 2006 - 7:34 AM

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

Technical Support Apr 20, 2006 - 7:41 AM

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


Thomas Maurer Apr 21, 2006 - 12:05 AM

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

Technical Support Apr 21, 2006 - 7:10 AM

The MDI and MDIDOCVIEW samples are simplest possible MDI projects with and without the document/view architecture. The Ctrl+Tab and Ctrl+Shift+Tab key combinations are working there "as is" without registering these keys in the accelerator table or using message pre-translation for them. So, we can learn deeper the source of this problem only by debugging your project which demonstrates the problem.

We still guess these keys are filtered incorrectly by some part of your program. This can be either an MFC class or an ActiveX object which also takes participation in the keyboard message filtering.