Since events are quite an important part of a GUI system, it probably wants a little bit written about how to use them in wxMax :-)
The Connect(), ConnectAny() and ConnectRange() methods
These three methods are the keys to hooking up your application to wxMax's event framework.
Each works slightly differently, but they all share the common purpose of allowing you to provide a callback function to which a particular event will be passed.
Here are the APIs :
The eventType parameter defines what type of event you are interested in catching. Each control can define its own events, as well as having the ability to raise events common amongst the rest. Typical event types might be, wxEVT_COMMAND_BUTTON_CLICKED (for a wxButton), wxEVT_COMMAND_TEXT_UPDATED (the result of typing into a wxTextCtrl) and wxEVT_ENTER_WINDOW (the mouse moving into a control).
Any given control can be connected to many events.
Controls in wxMax can have a unique ID attached to them when they are created, which can be used by you to specify interest in a particular control.
ConnectAny doesn't include an ID parameter as it is designed to basically work for any controls that raise the event.
Connect and ConnectRange specify the contol ID to monitor, with the latter also giving the last-ID in a range of controls which it will catch events for. Ranges are useful for handling events generated by Menus or Toolbars, where it is common to have the items in a numeric sequence.
The callback is a function pointer to a function taking a wxEvent object as a parameter. The wxEvent object can then be cast to the appropriate "real" event, so to acquire specific information.
With userData, you can supply an Object that will be passed back with the event in the wxEvent object.
Finally, sink allows you to do some more advanced event handling, by specifying a different wxEvtHandler to own the event. Normally not required.
As a small example, we're now going to take a look at the minimal sample, and examine how it connects to the Quit menu item.
In the sample, the menu item is created like so
The parameter wxID_EXIT is a special unique ID for this particular purpose (on Mac, you need to use this ID to allow the Quit menu item to be placed in the proper application menu). By specifying an ID, we allow ourselves the luxury of connecting an event to that menu item. Otherwise, how would we know what menu item we'd clicked on?
Here we are connecting a wxEVT_COMMAND_MENU_SELECTED event type to the ID. When the event is raised, it will call our function OnQuit(event:wxEvent) :
..which closes the window (and since this is our only window, automagically quits the application too!).
As you can see, with the event framework, it's just a case of connecting a particular event to a control and a callback function.
:o)
The Connect(), ConnectAny() and ConnectRange() methods
These three methods are the keys to hooking up your application to wxMax's event framework.
Each works slightly differently, but they all share the common purpose of allowing you to provide a callback function to which a particular event will be passed.
Here are the APIs :
Method ConnectAny(eventType:Int, callback(event:wxEvent), userData:Object = Null, .. sink:wxEvtHandler = Null) Method Connect(id:Int = -1, eventType:Int, callback(event:wxEvent), userData:Object = Null, .. sink:wxEvtHandler = Null) Method ConnectRange(id:Int, lastId:Int, eventType:Int, callback(event:wxEvent), userData:Object = Null, .. sink:wxEvtHandler = Null)
The eventType parameter defines what type of event you are interested in catching. Each control can define its own events, as well as having the ability to raise events common amongst the rest. Typical event types might be, wxEVT_COMMAND_BUTTON_CLICKED (for a wxButton), wxEVT_COMMAND_TEXT_UPDATED (the result of typing into a wxTextCtrl) and wxEVT_ENTER_WINDOW (the mouse moving into a control).
Any given control can be connected to many events.
Controls in wxMax can have a unique ID attached to them when they are created, which can be used by you to specify interest in a particular control.
ConnectAny doesn't include an ID parameter as it is designed to basically work for any controls that raise the event.
Connect and ConnectRange specify the contol ID to monitor, with the latter also giving the last-ID in a range of controls which it will catch events for. Ranges are useful for handling events generated by Menus or Toolbars, where it is common to have the items in a numeric sequence.
The callback is a function pointer to a function taking a wxEvent object as a parameter. The wxEvent object can then be cast to the appropriate "real" event, so to acquire specific information.
With userData, you can supply an Object that will be passed back with the event in the wxEvent object.
Finally, sink allows you to do some more advanced event handling, by specifying a different wxEvtHandler to own the event. Normally not required.
As a small example, we're now going to take a look at the minimal sample, and examine how it connects to the Quit menu item.
In the sample, the menu item is created like so
fileMenu.Append(wxID_EXIT, "&Quit~tAlt-Q", "Quit this program")
The parameter wxID_EXIT is a special unique ID for this particular purpose (on Mac, you need to use this ID to allow the Quit menu item to be placed in the proper application menu). By specifying an ID, we allow ourselves the luxury of connecting an event to that menu item. Otherwise, how would we know what menu item we'd clicked on?
Connect(wxID_EXIT, wxEVT_COMMAND_MENU_SELECTED, OnQuit)
Here we are connecting a wxEVT_COMMAND_MENU_SELECTED event type to the ID. When the event is raised, it will call our function OnQuit(event:wxEvent) :
Function OnQuit(event:wxEvent) ' true is to force the frame to close wxWindow(event.parent).Close(True) End Function
..which closes the window (and since this is our only window, automagically quits the application too!).
As you can see, with the event framework, it's just a case of connecting a particular event to a control and a callback function.
:o)