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
|
means that the event originated from a keyboard context button event, and you
|
||||||
should compute a suitable position yourself, for example by calling wxGetMousePosition().
|
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
|
Notice that the exact sequence of mouse events is different across the
|
||||||
with default position is sent first, and if this event is not processed, the
|
platforms. For example, under MSW the context menu event is generated after
|
||||||
context menu event is sent. So if you process mouse events and you find your
|
@c EVT_RIGHT_UP event and only if it was not handled but under GTK the
|
||||||
context menu event handler is not being called, you could call wxEvent::Skip()
|
context menu event is generated after @c EVT_RIGHT_DOWN event. This is
|
||||||
for mouse right-down events.
|
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}
|
@beginEventTable{wxContextMenuEvent}
|
||||||
@event{EVT_CONTEXT_MENU(func)}
|
@event{EVT_CONTEXT_MENU(func)}
|
||||||
|
Reference in New Issue
Block a user