Using 19.2, I have an app with a ribbon that has a custom control hosting an UltraTextEditor. When the focus is in this control and the user presses the ALT key sometimes the ribbon shortcuts are not shown, and the application File menu is shown instead (even though Ribbon.FileMenuStyle is set to None)
I have verified that the custom control does receive the WM_SYSKEYDOWN with keyData == Menu | Alt
I have another app that has a ribbon with no custom controls and it always works as expected (ALT shows ribbon shortcuts).
This seems bug-like, but I'm wondering if there is a way I could just work around it by forcing the shortcuts to appear in the ribbon? Is there even an API to do that?
Hello Todd,
In order to address the issue, the problem will need to be consistently reproducible.
Generally the window menu does not have shortcut by default, and is triggered by mouse right click on top of the window. I can suggest using windows hooks to see if you are not somehow getting additional input.
The fact that the commands in the window menu have their shortcuts highlighted does indeed mean that the alt keystroke was registered.
Is it possible that you set focus of the control by simulating mouse click on it, because mouse click + alt at the same time produces the result shown.
Please let me know if you have any additional info that could help identify the reason behind this.
Sincerely,Tihomir TonevAssociate Software DeveloperInfragistics
Hi Tihomir,
Thanks for your response. The problem is 100% reproducible. When the app first starts up the focus is in the control. Pressing ALT the first time always drops down the file menu. If the file menu is closed, then subsequent presses of ALT cause the ribbon shortcuts to appear, even though the focus has not changed. Another way to get it to consistently happen is to put the focus to somewhere outside of the ribbon in the application, and then back into custom control in the ribbon and hit ALT.
Also I verified that right clicking in the top of the window shows the window menu.
I have tried reproducing the issue on my end, however to no avail.
Would it be possible to post a an isolated sample where the described behavior is present, so I can investigated it further.
As the website has some restrictions of file upload size, please strip it of all unnecessary data, and delete the bin & obj folders to reduce the size of the zip.
Looking forward to your reply.
I created a simple solution to demonstrate the issue. To duplicate, run and then hit tab to change the focus to the custom control. Now when you press ALT you will see the window menu. Let me know if you have any other questions. Thanks!
AltKeyDemo.zip
I have ran the sample and the behavior described comes from the custom control. When you have overwritten the ProcessCmdKey method, and you return ProcessCmdKey(Message, Keys), the control will check if the current one has a context menu. In case it does not, it will look for the context menu of its parent, and keep going up until it finds one, which in this case is the window menustrip.
What you can do is to either configure a context menu to be associated with the control, and have it pop up when you press alt, or you can overwrite the default behavior by adding
if (keyData == (Keys.Alt | Keys.Menu)) { DoSomething(); return true; }
to your protected override bool ProcessCmdKey(ref Message msg, Keys keyData) method.
Should you have any further questions or concerns, please let me know.