Command routing problem with CMFCMenuBar

Hi itsmeandnobodyelse,

thanks for the reply - but, my problem ist not the update-mechanism, my problem is that menu-commands can be called via shortcut while the view has the capture.

My application is a CAD like application with a complex GUI within a CScrollView. There are about 15 or more dialogs which can be opened via shortcuts while no drag operation in the view is active. As soon as the user starts a drag-operation the capture is set to the view, it's released when the drag operation finished.

With 'old' MFC there was no problem since menu commands weren't executed with their shortcuts as long as capture was set. With 'new' MFC (or better said as soon as a CMFCMenuBar is involved) this doesn't work anymore.

Of course now I coul implement a ON_UPDATE_COMMAND_UI handler for each of these menue commands, but I'm searching for a more generic way to get this working as it did in 'old' MFC.

In MSDN about 'SetCapture' there's this statement:
> When the mouse is captured, menu hotkeys and other keyboard accelerators do not work.

This in fact is not the case anymore when using the CMFCMenuBar.


Regards,

ZOPPO

>>>> can be called via shortcut while the view has the capture.
Your accelerators (shortcuts) wouldn't be able to invoke menu functions (or toolbar buttons) when the items or buttons were disabled. Enabling/disabling of menu functions happens in the UpdateUI handler functions which were called at idle times, i. e. when the message pump is not busy.

>>>> With 'old' MFC there was no problem since menu commands weren't executed with their shortcuts as long as capture was set.
That seems to have been a bug rather than a feature. I doubt that it makes much sense to ignore shortcuts while the mouse is captured - as a general restriction (though of course it is bad if you have written code which was based on that). Normally the user must not be aware of mouse capturing (though you might have changed cursor shape) and then might be confused if short-cuts were not working.  

>>>> I could implement a ON_UPDATE_COMMAND_UI handler for each of these menue commands, but I'm searching for a more generic way to get this working
Hmm. The UI handlers is the MFC way to do this. You hardly will find a better solution which has not some drawbacks. BTW, you could create the UPDATE_COMMAND_UI handlers  using the wizard and replace then all handler functions in the message map by one single handler. That way the efforts seem to manageable. You even could call the one and only UI handler function when capturing/releasing the mouse, thus regaining the *lost* feature from old MFC.

Sorry, I don't agree.

>> That seems to have been a bug rather than a feature.
First as told in MSDN exactly this behavior is stated: 'When the mouse is captured, menu hotkeys and other keyboard accelerators do not work'. We started developing that mentioned application with MSVC++ 4.0 and since then that behavior wasn't changed (even with VS 2008 it's the same as long 'normal' menues are used). There we implemented the shortcuts which can be used while the mouse is captured via handling WM_KEYDOWN/WM_KEYUP messages. This worked fine the last 10 years.

IMO this modified behavior of 'new' MFC is a bug and I'd like to find a workaround to get it working as it did before.

Of course I know about the UpdateUI-handler functionality. As told I would like to get the 'new' MFC work as the 'old' one did to avoid the need of changing/adding UPDATE_COMMAND_UI handlers for all possible shortcuts since there are a lot of these which handles the states in different situations and I fear it would take me (and our testers) a lot of time to find all commands which handlers need to be changed.

BTW: Did you already do something with MFC FeaturePack's new classes? I did and found that there are some bugs inside and even some things which IMO are not designed very well - I implemented lot of 'new' GUI elements in our application and had to implement quite a lot workarounds to get it running as expected ...

Best regards,

ZOPPO

The CWnd::PreTranslateMessage runs before accelerators were handled - or better said the CDialog::PreTranslateMessage or CFormView::PreTranslateMessage actually were handling the accelerators. So, you could overload these functions, check for the mouse being captured and call the baseclass function only if you want the accelerators to be handled.

>>>> Did you already do something with MFC FeaturePack's new classes?
No, my current project is a huge MFC based framework which recently was ported from VC6 to VC7. It uses only basic MFC controls (plus list control and tree control) as they have been since the beginning of MFC. So, I know the new features from EE questions only.

Have you installed Vs2008 Service Pack 1 (released in August)?  A number of bugs were fixed.

>>>>> I found no way to handle these in PreTranslateMessage
Did you overload CMainFrame::PreTranslateMessage as well?

The accelerators (e. g. Alt-F) were all handled in the TranslateMessage of your message loop (in CWinThread::Run) what leads to (virtual) calls of the PreTranslateMessage of the targeted CWnd derived class.

Hi,

@DanRollins: Yes, I have installed it ...

@itsmeandnobodyelse: I tried PreTranslateMessage in MainFrame, ChildFrame, App and View classes. As written above I can debug it down to the call of '::TranslateAccelerator' in 'CMDIFrameWnd::PreTranslateMessage'. If this is called the menue pops up without a further call to any of the above mentioned classes PreTranslateMessage.

Regards,

ZOPPO

That is strange. I seriously had the same case where I finally found  the translation in CDialog::PreTranslateMessage.

You might set a breakpoint into CWnd::PreTranslateMessage in order to find the window which translates the shortcuts ...