I was fiddling with Windows SpellCheck in InkEdit controls, and I ran into trouble with having both right-click SpellCheck correction and "normal" editing menus (cut, paste, bold, etc.) work for the same InkEdit.
Then I realized most of our common silly code catching MouseDown events is in error anyway and we really ought to handle "menu" button presses (both the special Windows Menu key on newer keyboards and the Shift-F10 combination) as well.
But... subclassing the RTF controls for WM_CONTEXTMENU only works for the keys and not right-clicks! I'm not sure but it might be something within RichEdit, possibly related to:
Q245754: BUG: Windows 2000 RichEdit Control Generates WM_CONTEXTMENU Message
... though that would suggest the opposite problem. I guess I'm wondering if these controls are trying to compensate for that "bug."
Setting aside SpellCheck for the moment, I created a test Project with a RichTextBox and a TextBox on a Form:
Anyone have a clue?
[BTW: Test in the IDE to see the Debug.Print results]
Then I realized most of our common silly code catching MouseDown events is in error anyway and we really ought to handle "menu" button presses (both the special Windows Menu key on newer keyboards and the Shift-F10 combination) as well.
But... subclassing the RTF controls for WM_CONTEXTMENU only works for the keys and not right-clicks! I'm not sure but it might be something within RichEdit, possibly related to:
Q245754: BUG: Windows 2000 RichEdit Control Generates WM_CONTEXTMENU Message
... though that would suggest the opposite problem. I guess I'm wondering if these controls are trying to compensate for that "bug."
Setting aside SpellCheck for the moment, I created a test Project with a RichTextBox and a TextBox on a Form:
- Both the keystrokes and mouse right-click work for the TextBox.
- Only the keystrokes work for the RichTextBox.
Anyone have a clue?
[BTW: Test in the IDE to see the Debug.Print results]