Explain EVT_CONTEXT_MENU generation in more details.
Document that you should not count on specific order of mouse right button and context menu events. Closes #12535. git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@72542 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
@@ -2861,11 +2861,15 @@ public:
|
||||
means that the event originated from a keyboard context button event, and you
|
||||
should compute a suitable position yourself, for example by calling wxGetMousePosition().
|
||||
|
||||
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.
|
||||
Notice that the exact sequence of mouse events is different across the
|
||||
platforms. For example, under MSW the context menu event is generated after
|
||||
@c EVT_RIGHT_UP event and only if it was not handled but under GTK the
|
||||
context menu event is generated after @c EVT_RIGHT_DOWN event. This is
|
||||
correct in the sense that it ensures that the context menu is shown
|
||||
according to the current platform UI conventions and also means that you
|
||||
must not handle (or call wxEvent::Skip() in your handler if you do have
|
||||
one) neither right mouse down nor right mouse up event if you plan on
|
||||
handling @c EVT_CONTEXT_MENU event.
|
||||
|
||||
@beginEventTable{wxContextMenuEvent}
|
||||
@event{EVT_CONTEXT_MENU(func)}
|
||||
|
Reference in New Issue
Block a user