.. wxPython Phoenix documentation
This file was generated by Phoenix's sphinx generator and associated
tools, do not edit by hand.
Copyright: (c) 2011-2020 by Total Control Software
License: wxWindows License
.. include:: headings.inc
.. currentmodule:: wx.lib.agw.aui.auibar
.. highlight:: python
.. _wx.lib.agw.aui.auibar.ToolbarCommandCapture:
==========================================================================================================================================
|phoenix_title| **wx.lib.agw.aui.auibar.ToolbarCommandCapture**
==========================================================================================================================================
A class to handle the dropdown window menu.
|
|class_hierarchy| Class Hierarchy
=================================
.. raw:: html

Inheritance diagram for class
ToolbarCommandCapture:
|
|super_classes| Known Superclasses
==================================
:class:`wx.EvtHandler`
|
|method_summary| Methods Summary
================================
================================================================================ ================================================================================
:meth:`~wx.lib.agw.aui.auibar.ToolbarCommandCapture.__init__` Default class constructor.
:meth:`~wx.lib.agw.aui.auibar.ToolbarCommandCapture.GetCommandId` Returns the event command identifier.
:meth:`~wx.lib.agw.aui.auibar.ToolbarCommandCapture.ProcessEvent` Processes an event, searching event tables and calling zero or more suitable
================================================================================ ================================================================================
|
|api| Class API
===============
.. class:: ToolbarCommandCapture(wx.EvtHandler)
A class to handle the dropdown window menu.
.. method:: __init__(self)
Default class constructor.
.. method:: GetCommandId(self)
Returns the event command identifier.
.. method:: ProcessEvent(self, event)
Processes an event, searching event tables and calling zero or more suitable
event handler function(s).
:param `event`: the event to process.
.. note:: Normally, your application would not call this function: it is called
in the wxPython implementation to dispatch incoming user interface events
to the framework (and application).
However, you might need to call it if implementing new functionality (such as
a new control) where you define new event types, as opposed to allowing the
user to override functions.
An instance where you might actually override the :meth:`ProcessEvent` function is where
you want to direct event processing to event handlers not normally noticed by
wxPython. For example, in the document/view architecture, documents and views
are potential event handlers. When an event reaches a frame, :meth:`ProcessEvent` will
need to be called on the associated document and view in case event handler
functions are associated with these objects.
The normal order of event table searching is as follows:
1. If the object is disabled (via a call to :meth:`~EvtHandler.SetEvtHandlerEnabled`) the function
skips to step (6).
2. If the object is a :class:`wx.Window`, :meth:`ProcessEvent` is recursively called on the window's
:class:`wx.Validator`. If this returns ``True``, the function exits.
3. wxWidgets `SearchEventTable` is called for this event handler. If this fails, the
base class table is tried, and so on until no more tables exist or an appropriate
function was found, in which case the function exits.
4. The search is applied down the entire chain of event handlers (usually the chain
has a length of one). If this succeeds, the function exits.
5. If the object is a :class:`wx.Window` and the event is a :class:`CommandEvent`, :meth:`ProcessEvent` is
recursively applied to the parent window's event handler. If this returns ``True``,
the function exits.
6. Finally, :meth:`ProcessEvent` is called on the :class:`App` object.