How a Desktop Application Works
A Uniface desktop application is a traditional client/server application which can run on a local machine with access to remote functionality when needed.
It consists of an application shell and one or more form components that are run locally, and service and report components that are usually run on a remote server.
In Uniface, the term client/server application refers to a stateful application with a user interface, which can run in a distributed environment. It can be a standalone desktop application, or it can be distributed to have service and report components run on network servers and form components run on local workstations or terminals.
Users start the application by executing the
application shell using the Uniface executable. For example, uniface.exe myapp.
When the application shell is run, it immediately activates a form component and passes control to it. When the form is started, Uniface starts an edit session and creates an in-memory data structure. This represents all the data in all the open forms, including the active path that determines which data is processed.
Event Processing
Processing occurs in response to events in the application's event input queue. This queue is managed by an event manager known as the structure editor, which maintains the in-memory data structure and ensures that all processing occurs in correct order. For example, if a user edits a field, the in-memory data structure is modified and the event manager implicitly executes triggers to perform data validation or syntax checking.
Event processing is dependent on the context, meaning that events in the queue are not processed until certain conditions are met. The structure editor recognizes the context and if it is not correct, activates appropriate triggers to set the context correctly, for example, by validating data. If errors are encountered, further processing may be stopped.
Uniface creates a edit session for each open form. Edit sessions can be nested when one form activates another modal form, and parallel sessions are maintained when non-modal forms are run. The more forms that are open at any one time, the more complicated the in-memory data structure becomes, particularly if non-modal forms are used.
For more information, see Structure Editor.
Events and the Event Input Queue
An event is a signal that something specific has happened which may require a response. Events occur in response to:
- User actions, such as moving the cursor in the form or editing data.
- Asynchronous messages from outside the form. For more information, see Asynchronous Messaging.
- ProcScript instructions that are executed inside the form, such as a macro command.
As events occur, they are added to the event input queue. Each event in the queue activates a structure editor function, which is a request for the structure editor to do something. The resulting application behavior depends on whether the behavior is defined by the developer, by the default trigger code, or by Uniface itself.
Some events occur in sequences. For example, when
a user clicks a Store button, this activates a detail
trigger containing a macro "^STORE" command, which activates the ^STORE structure
editor function, which initiates a sequence of write events for each occurrence of each entity in
the form.
Note: The trigger flow from the structure editor for interactive triggers differs slightly for modal and non-modal forms. This is important when writing exception-enabled code in order to handle exceptions that may bubble up. For more information, see Interactive Trigger Flow in Forms.
Fields in Form Components
In form components, many field-level events are initiated by the user via structure editor functions. They are meant for simple cause-and-effect processing, such as telling Uniface which field is the next to be prompted. Use the startModification and loseFocus triggers to check the data in a field as the user works. (The startModification trigger is activated when a user tries to modify a field, and allows you to test for the first character entered.)
Note: Many text editing functions, and all functions for navigation within a field, are meaningless for most widget types except unifields. All functions are valid in character mode, if the context is correct. All functions starting with ^CURSOR are also valid at component level in character mode.
