views:

350

answers:

1

I'm trying to add context menus into a (large) custom control in my application but have run into a number of issues with when to create them.

There are 3 cases when a context menu needs to be created (unless I forgot one...) on a right mouse click, when the menu key is pressed and for Shift + F10. In all cases the menu is created and displayed by a ContextMenu method.

The right mouse does some other special stuff and so shouldn't always create a context menu. I'm handling the various mouse events and call ContextMenu as needed, which is all working nicely.

The problem is with the keyboard generated context menus. I've set a handler in my control for EVT_CONTEXT_MENU which then just calls ContextMenu. In a lot of cases both key combinations appear to just be ignored. Sometimes the Shift+F10 works correctly, but in the same cases the menu key is somehow invoking my right mouse click handlers, resulting in incorrect behaviour...

For the menu key I also tried handling the key events, but the menu key never seems to trigger these in wxWidgets although all the other keys seem to work fine...

  1. Why are the key methods somehow ignored by wxWidgets. They should work as long as the control has focus. When they start "working" they keep working until it looses focus again, but im not sure why they don't to start with or what is causing them to start working (I don't handle any context menu or key events anywhere else in my test app).

  2. How is the menu key event getting into my EVT_RIGHT_UP handler instead of the key events or context menu events?

I assume it is something fundamentally wrong with my understanding of how wxWidgets handles these keys, however having looked around the documentation and on the net for some time I haven't found any info regarding my issues.

I am using wxMSW 2.8.10 on Windows Vista.

+1  A: 

wxWidgets is a library to abstract away platform differences, like which mouse or key events should result in a context menu to appear. There may be differences like whether it appears on mouse down, or on mouse up, or even (on the Mac) on Ctrl+click of the single mouse button.

You should therefore not handle mouse and keyboard events directly, but handle the wxContextMenuEvent instead. Note that it will be called after both mouse and keyboard events:

Note that if wxContextMenuEvent::GetPosition returns wxDefaultPosition, this means that the event originated from a keyboard context button event, and you should compute a suitable position yourself, for example by calling wxGetMousePosition().

Note that you can also suppress the event for some mouse events and have it generated for others:

When a keyboard context menu button is pressed on Windows, a right-click event with default position is sent first, and if this event is not processed, the context menu event is sent. So if you process mouse events and you find your context menu event handler is not being called, you could call wxEvent::Skip() for mouse right-down events.

Hopefully replacing your current code for context menus with handlers for this event will work. For all mouse events that should also cause the context menu to appear you would need to call event.Skip(), maybe not doing this is the reason you are getting inconsistent results now.

mghie
As I said I AM using the wxContextMenuEvent, but for some reason its not getting called/triggered. I need to handle the mouse events in my control for other stuff, but that bit is working fine. Its just why the wxContextMenuEvent does not get called reliably for the windows context menu key combinations in the first place.
Fire Lancer
Ok, that explains why Its somehow getting trapped in the mouse handler, and I guess I just need to check and skip any mouse events at (-1,-1). But that doesnt explain why wxWidgets seems to loose the event entirely sometimes, ie none of my handlers are called for either the menu button, or shift + f10?
Fire Lancer
It's hard to say, I haven't had problems with `wxContextMenuEvent` alone. If the keyboard events don't work either, maybe it's a focus issue? But anyway, I wouldn't `Skip()` only events at (-1, -1), I would call it for *all* events unless the context menu needs to be suppressed, and then for all coordinates.
mghie