WxWidgets event processing

The handler tells the correspondence between the wxWidgets event and the event processing process. All window classes inherited from wxwindow and Applications Program Classes are all derived classes of wxevthandler. The following steps are required to create a static event table (during compilation:
(1) define a class that directly or indirectly inherits from wxevthandler;
(2) define a processing function for each time you want to process;
(3) Declare the event table using declare_event_table in this class;
(4) use begin_event_table and end_event_table In the. cpp file to implement an event table
(5) add event Macros in the implementation of the event table to map events to the event processing process. Event table:
Begin_event_table (myframe, wxframe)
Evt_menu (wxid_exit, myframe: onexit)
Evt_size (myframe: onsize)
Evt_button (button1, myframe: onbutton1)
End_event_table () macro begin_event_table declares that wxframe and its subclass myframe have this event table. The member functions that process events cannot be virtual. In fact, the event processor ignores virtual declarations. The event processing function has the same form: the return type is void and an event object is accepted as the parameter number. The type of this parameter is related to the specific event. For example, the parameters of the event command processing function for simple controls (such as buttons and menus) are of the wxcommandevent type, while the size event is of the wxsizeevent type. The evt_size event ing macro does not need to mark parameters, because this event will only be processed by the control that generates this event. Event transmission process:
When an event is received, wxwindows first calls the wxeventhandler procssevent processor on the object that generates the event in the window. Wxwindow (and other window classes) are inherited from wxeventhander. Processevent searches for each event in the event table and calls zero or multiple event processor functions. The following are the steps to process an event: 1. When the object is closed (including the setevthandle of wxevthandler), the function jumps to Step 6.
2. if the object is a wxwindow object, processevent recursively calls the wxvalidator object in the window. If the true function is returned, exit.
3. searcheventtable is a function called by the event processor. When it fails, it begins to try on the base class until there are no more event tables or a suitable function is found, and the function exits. The detected function is executed.
4. The search process is applied to the entire event processor chain. When the application is successful, the function exits.
5. When the object is a wxwindow object and the event is of the wxcommandevent type, processevent is recursively applied to the event processor of the parent window. When it returns true, the function exits. This allows the father of a button to process button clicks rather than the button himself.
6. Finally, processevent is called on the wxapp object. After you click OK, A new wxcommandevent event is created, which contains the identifier button_id_ OK and the event type wxevt_command_button_clicked. Then, the event table of this button starts to match through the wxevthandler: processevent function, every entry in the event table will try to match, followed by its parent wxcontrol class event table, followed by wxWidgets. If no match is found, wxWidgets searches the class event table of its parent window. Then, a matching entry: EVT button (button_id_ OK, textframe: onbuttonok) is found. Therefore, the textframe: onbuttonok function is called. Note: only command events (which directly or indirectly inherit from wxcommandevent events) are recursively applied to the event table of its parent window. Events that are not passed are as follows:
Wxactivate, wxcloseevent, wxeraseevent, events, wxkeyevent, wxidleevent, events, events, wxmenuevent, wxmouseevent, wxmoveevent, events, wxsizeevent, events, and events, these events are not transmitted to the parent window of the event source control. Filter events:
You can modify the default behavior of local native controls. For example, filter key events. For example, only digital input is allowed. At this time, we should inherit a new wxtextctrl class, and then use the evt_key_down event ing macro in its event table. Processevent exits after discovering a function that can process events. This indicates that when your class reacts to an event, the lower class will not get this event. Sometimes we don't want this. This problem can be solved by using the wxevent skip Method Based on the event type of the base class, so that the event processor can continue searching. Void mytextctrl: onchar (wxkeyevent & event)
{
If (wxisalpha (event. keycode ()))
{
Event. Skip ();
}
Else
{
Wxbell ();
}
} Mount event table:
It is not necessary to implement a new class inherited from a class to change its event table. For Classes inherited from wxwindows, there is another way! You can implement a new class that directly inherits from wxevthandler, define the event table of the new class, and then use wxwindow :: the pusheventhandler function pushes the event table to the event table stack of a window class. The last event table will be matched first in the event matching process. If the event table does not match the corresponding event processing process, the previous event table in the stack will still be matched. You can also use the wxwindow: popeventhandler function to pop up the top-level event table. If you pass the true parameter to the wxwindow: popeventhandler function, the event table will be deleted. Consider the following: Each menu command must be recorded. A solution is to create a function called in each command event processing function. This method makes maintenance very difficult. When a new menu is added and this function is not called, this menu command is not recorded. To solve this problem, create a new event processor and add it to a wxwindow class. To complete this operation, you must create a new class derived from wxevthandler. Processing events in the new class is the same as a normal window. Logeventhandler. H-Definition of logeventhandler # ifndef _ logeventhandler_h
# DEFINE _ logeventhandler_h
Class logeventhandler: Public wxevthandler
{
Public:
Logeventhandler (): wxevthandler ()
{
}
Virtual ~ Logeventhandler ()
{
}
Protected:
Declare_event_table ()
Void onmenu (wxmenuevent & event );
PRIVATE:
};
# Endif // _ logeventhandler_h
Implementation of logeventhandler. cpp-logeventhandler // for compilers that supports precompilation, between des "wx/wx. H"
# Include "wx/wxprec. H"
# Ifndef wx_precomp
# Include "wx/wx. H"
# Endif
# Include "logeventhandler. H"
Void logeventhandler: onmenu (wxmenuevent & event)
{
Wxlogmessage ("Someone selected a menu item ");
Event. Skip ();
}
Begin_event_table (logeventhandler, wxevthandler)
Evt_menu_range (-1,-1, logeventhandler: onmenu)
End_event_table () in the macro evt_menu_range, all menu events can be processed. The first two parameters are used to specify the ID range of the menu to be processed. -1 indicates processing all menu items. Do not forget to call skip on the event. Otherwise, no event will be transmitted to the event processor of the wxwindow class.
The next step is to press the new event processor into the processor stack. This is done using pusheventhandler of wxwindow. To remove the event processor from the stack, use popeventhandler. Pusheventhandler (New logeventhandler ()); Dynamic event processing:
The dynamic ing method allows you to more accurately control the details of the event table. You can even independently open or close an entry in the event table at runtime. Pusheventhandler and popeventhandler can only process the entire event table. Dynamic event processing also allows you to share event functions between different classes. Functions related to dynamic events include: Wxevthandler: connect And Wxevthandler: disconnect .
In most cases, the wxevthandler: disconnect function is not required. This function is automatically called when the form class is released. Class myframe: Public wxframe
{
Public:
Myframe (const wxstring & title );
Void onquit (wxcommandevent & event );
Void onabout (wxcommandevent & event );
PRIVATE:
};
Declare_event_table is not used to declare an event.
In this case, add the following to the oninit function: Code : Frame> connect (wxid_exit,
Wxevt_command_menu_selected,
Wxcommandeventhandler (myframe: onquit ));
Frame> connect (wxid_about,
Wxevt_command_menu_selected,
Wxcommandeventhandler (myframe: onabout); the three parameters passed to the connect function are the menu identifier, event identifier, and event processing function pointer. Here, wxevt_command_menu_selected is different from evt_menu. In fact, the evt_menu also uses wxevt_command_menu_selected.evt_menu to automatically include the macro wxcommandeventhandler () used to forcibly convert the event pointer type (). generally, if the parameter type of the event handler is wxxyzevent, the type of the handler should be forcibly converted using the wxxyzeventhandler macro. If you want to terminate the above event processing, it should be: frame> disconnect (wxid exit,
Wxevt command menu selected,
Wxcommandeventhandler (myframe: onquit ));
Frame> disconnect (wxid about,
Wxevt command menu selected,
Wxcommandeventfunction (myframe: onabout )); Window identifier:
The window identifier is the unique integer used to determine the window in the Event System. Within the scope of the application, the window identifier does not have to be unique, as long as it is in a fixed context (such as in a frame window and all its word Windows) is unique. If wxid_any is used as its identifier in the window constructor, it means that you want wxWidgets to automatically generate a identifier for you. WxWidgets automatically creates a negative sign. Therefore, it will never be the same as the User-Defined identifier. the user-defined identifier can only be a positive integer. Custom events:
(1) derive your own time class from an appropriate event class, declare dynamic type information, and implement a clone function, add new data members and function members as you wish. If you want to transfer the time between window inheritance relationships, you should use the wxcommandevent derived class, if you want the event processing function to call veto, you should use the derived class of wxpolicyevent.
(2) define a type for the processing function of this event class.
(3) define a table of event types supported by your event class. This table should be defined in your header file. In_declare_event_types () macro and end_declare_event_tabel (name, integer) macro are used. Then use define_event_type (name) in your. cpp file to implement this event class.
(4) define an event ing macro for each event supported by your event class. Code attachment (mainly including defining the filtering time and dynamically associating the time to a button. Others are the same as the previous framework)