Event handling
Database applications generate internal events usually indicating data modifications but also state changes in access handles (open, close, select instance etc.). Events may be received by event handlers (overloaded functions written in C++, C# or OSI), but may also be passed by process event handlers to other application components. Thus, database events are sent to GUI framework (when being used), in order to indicate state changes in data or access handles.
In addition, the GUI framework generates a number of GUI events indicating state transitions in a GUI element (typically controls) or triggering an action. Similar to database events, GUI events may be overloaded by appropriate event handler functions.
Database events are generated in order to signal different kinds of state transition referring to database resource or access handle state. Most events are designed as before- and after-events. Before-events may be used to suppress the state change in process.
- Handle events - are generated, when opening or closing an access handle or when changing selected data in an access handle
- Resource events - are generated, when database resources change, i.e. while creating, updating, storing or deleting instances or while removing or inserting instances from/into collections. Resource events are also generated when the intended state transition failed.
- Server events - in order to synchronize states between client and server, the server sends events generated while processing a request back to the client, which also generates the events returned.
- Application events - are user-defined events associating a special state transition or the database resource (e.g. income becomes greater than 10 000 ) with a specific (re)action. When the event is generated, the defined action is called in order to handle the event.
Handle and resource events are generated on instance and property level, i.e. events are also generated for elementary attributes.
Application events - are user-defined events associating a special state transition or the database resource (e.g. income becomes greater than 10 000 ) with a specific (re)action. When the event is generated, the defined action is called in order to handle the event.
GUI framework events are generated in order to signal different kinds of state transition referring to GUI resource. Most events are designed as before- and after-events. Before-events may be used to suppress the state change in process. There are two kinds of GUI framework events.
- Data events - are generated, when opening or closing the data source for a GUI resources, or when data in the GUI resource has been filled, updated or changed in another way.
- GUI events - are generated, the state of a GUI resource (typically control) changes, e.g. when a control is opened or closed, or receives or loses focus.
- Application events - are user-defined events associating a special state transition or the GUI resource (e.g. pressing keys Shift+Alt+I when the GUI resource has the focus) with a specific (re)action. When the event is generated, the defined action is called in order to handle the event.
The principles for handling events do not differ between GUI and database event. Mainly, events are handled in Context Classes assigned to database or GUI resources. There are three different ways of handling database events:
- Overloaded event handler - In order to handle events, context classes have to be defined for corresponding database resource (database, object space, data type, property). Events generated call virtual event handler functions (dummy functions) that may be overloaded in the context class (OSI, C++, C#)
- Process event handler - In order to provide kind of generic event handling, process event handlers may be provided. Process event handler register themselves to a property handle in order to receive property and instance events.
- Associated action - Within GUI framework, but also for database, application events may be handled by associated actions. Actions are either function actions implemented in the context class of the database or GUI resource or associated window actions (e.g. requesting authorization before increasing the income),