||<< Index >>||
|Appendix N - Events||appendix|
Which events should my app intercept?
An event's "default behavior", as mentioned above, is an important consideration; many times it provides exactly what the app requires (and what a user expects) and no further code is necessary. Imagine a text field on your app's window and the user typing text into a text field. Every time the user presses a keyboard key, an event is sent to your application (actually two events - one for key down and one for key up when the user releases the key). Most of the time an app wouldn't need to know a user has typed text into a text field, so your app would just ignore the message/event and allow the default behavior to handle it.
Your app will process/intercept (more on event interception later) those events it needs to process.
This occurs if the app needs to process an event differently from the default behavior or needs to cache information for later processing.
For example, if your app allows the user to draw a rectangle in a window with their mouse/trackpad, the code needs to draw the rectangle and track the start point (x,y coordinates) of the rectangle (and the end point but we won't cover that).
In this case our app code should intercept/process the
_viewMouseDown event and save the rectangle's start point where the user clicked.
If our code doesn't process the
_viewMouseDown event it wouldn't know where to start drawing the rectangle because it wouldn't have the coordinates of the user's starting mouse click.
Events related to controls (i.e. user interface widgets such as buttons) in a window are usually intercepted because they indicate the user wants to do something. For example, a user presses a button labeled "Print". The app needs to intercept this and provide a printing interface for the user. When a control, like a button, is created either in code or in a nib (via Xcode's Interface Builder - not covered here) the programmer associates a unique tag (typically a numeric constant) with the button. When a button is pressed, the runtime sends the app a button click event. The app must intercept this button click event and then call code (often a function) to process the user's press of that button.
How to request events from the runtime
Intercepting events is a two-stage process as follows:
|Event request statement||Description and Operation|
|on appevent||Request delivery of all application level events|
|on dialog||Request delivery of all events except those provided by
|on menu||Request delivery of all menu events|
|HandleEvents||Start Application Events - required for apps that need to intercept events|
|ask runtime to send application events to my function named DoAppEvent|
|ask runtime to send non-menu and non-App events to my function named DoDialog|
|ask runtime to send menu events to my function named DoMenu|
|start event handling|
on menustatement. The code within the receiving function checks the received event against the event names it wants to intercept. Event names are represented by FB constants. The following discussion uses an FB example file, "ApplicationDemo" located in FB Examples/Application, to illustrate event interception with constants.
DoAppEventfunction shows how to intercept those events with those constants.
_windowWillClose. The "ApplicationDemo" example file and its