AG_Function) type represents an event handler (or more generally a virtual function)
AG_Object(3). It is the basis of Agar message passing.
Event handlers are tagged with a case-insensitive string up to
AG_EVENT_NAME_MAX bytes in size.
Anonymous functions are denoted by an empty tag.
Functions are declared as follows:
An AG_Event may store up to AG_EVENT_ARGS_MAX arguments. The arguments contained in an AG_Event can be accessed both by index and by name (names are case-insensitive strings up to AG_VARIABLE_NAME_MAX bytes). The argument stack contains the arguments from the initial AG_SetEvent() call first, followed by additional arguments tacked on by any subsequent AG_PostEvent() calls (see EVENT ARGUMENTS for more details and examples).
Agar objects can act as event senders or event receivers. Execution of event handlers can be delayed for a set amount of time, or marked for execution in a separate thread. AG_Event provides a thread-safe message passing system for multithreaded applications.
The AG_SetEvent() function registers a new event handler to service events of type name. If an event handler is already registered for the given event type, it is replaced. The AG_AddEvent() variant preserves any existing event handler, such that multiple handlers can be invoked when the event is raised. The fn argument is a pointer to the event handler function, and fnArgs is a special kind of format string specifying a list of arguments (see EVENT ARGUMENTS section).
The AG_FindEventHandler() function searches for an event handler by name, returning a pointer to the AG_Event element on success or NULL if there is no match.
AG_UnsetEvent() and AG_UnsetEventByPtr() delete the given event handler.
The AG_PostEvent() function immediately executes the event handler function associated with the given event type, if there is any. The fn and fnArgs arguments to AG_PostEvent() are interpreted in the same way as AG_SetEvent() and AG_AddEvent(), but the arguments are appended at the end of the argument list. When the event handler function retrieves arguments by index (as opposed to using argument names), it is important to remember that the arguments to AG_PostEvent() follow the arguments given to AG_SetEvent() or AG_AddEvent().
The AG_PostEvent() function returns 1 if an event handler was invoked, or 0 if there is no registered event handler for the specified event.
The AG_PostEventByPtr() variant accepts a pointer to an AG_Event element, as opposed to looking up the event handler by name.
The AG_SchedEvent() function provides an interface similar to AG_PostEvent(), except that the event is scheduled to occur in the given number of ticks AG_SchedEvent() returns 0 on success or -1 if the timer could not be created. If the object is detached or destroyed, all events scheduled for execution are automatically cancelled. A more flexible interface for implementing timers is described in AG_Timer(3) (which AG_SchedEvent() uses internally).
AG_SetEvent(), AG_AddEvent() and
AG_PostEvent() routines accept a special
fnArgs format string specifying a list of arguments to be passed to the event handler
For example, "%s,%p,%i" (or "%s%p%i") says that the following arguments are
a string, a pointer and an integer.
An event handler routine will typically use accessor macros to extract argument
values out of the
Agar object classes may define their own accessor macros. This includes AG_<T>_PTR() / AG_CONST_<T>_PTR() for accessing arguments by index, and AG_<T>_NAMED() / AG_CONST_<T>_NAMED() for accessing by name.
Since the first argument (argument 0) is always a pointer to the object receiving the event, the AG_<T>_SELF() and AG_CONST_<T>_SELF() macros may be used instead of "AG_<T>_PTR(0)" and "AG_CONST_<T>_PTR(0)".
Here is an example using Agar-GUI widget classes:
Arguments can be named and retrieved with AG_<TYPE>_NAMED():
The following argument specifiers are accepted:
The following macros extract the arguments contained in an AG_Event structure. If Agar is compiled with either --enable-debug or --enable-type-safety, they also check for potential accesses to incorrect types.
The AG_SELF() and AG_CONST_SELF() macros expand to a pointer to the AG_Object(3) receiving the event (the obj argument passed to AG_PostEvent()). They are equivalent to AG_PTR(0) and AG_CONST_PTR(0), respectively.
The following macros return a specific item in the list of arguments. When retrieving arguments by index, note that the arguments to AG_PostEvent() follow the arguments to AG_SetEvent() (i.e., the arguments to AG_SetEvent() are pushed first onto the argument stack, followed by the arguments to AG_PostEvent(), if any). These macros ensure type safety if Agar is compiled with --enable-debug or --enable-type-safety.
AG_PTR() returns a pointer (previously passed as a %p argument). AG_CONST_PTR() returns a pointer (previously passed as a %Cp argument).
AG_OBJECT() returns a pointer to an AG_Object(3) (previously passed as a %p argument). In debug mode, assert that the argument points to a valid AG_Object(3) by performing a validity test, and a class membership test. The AG_CONST_OBJECT() variant asserts that the object pointer was passed as "%Cp".
AG_STRING() returns a pointer to a string passed as a %s argument.
AG_INT(), AG_UINT(), AG_LONG() and AG_ULONG() return a natural or long integer passed as %i, %u, %li or %lu argument respectively.
AG_FLOAT() and AG_DOUBLE() return the given floating-point number, previously passed as a real %f or %d argument.
The AG_*_NAMED() macros retrieve the given argument by name instead of by index. If there is no argument matching the name, a fatal error is raised.
In some cases it is desirable for functions to accept a list of event handler
AG_SetEvent(), and possibly manipulate its entries directly.
For example, the
AG_MenuAction(3) function of the GUI widget
AG_Menu(3) accepts a pointer to an event handler function, followed by an
AG_SetEvent() style format string and a variable list of arguments.
The following functions allow such manipulations.
AG_EventInit() initializes an AG_Event structure with no arguments.
AG_EventArgs() initializes ev and also specifies a list of arguments (in the same format as AG_SetEvent()).
AG_EventCopy() copies the function pointer and arguments from one AG_Event to another. AG_EventDup() returns a newly-allocated duplicate.
The AG_EventPush*() routines put a new argument on top of the argument stack, incrementing the argument count. AG_EventPop*() decrement the argument count, returning a copy of the data of the last element.
The AG_EVENT_PUSH_ARG() macro insert an argument on the argument stack, determining the type from formatChar and the data from the following va_arg(3) arguments. The supported formatChar characters are documented in the EVENT ARGUMENTS section.
|Under some circumstances, it is useful to gather AG_Event objects into a simple queue. For example, a custom event loop routine (see AG_EventLoop(3)) or a low-level Agar driver (see AG_Driver(3)) may gather events from input devices and later process them.|
The following code fragment demonstrates a typical
AG_Event usage in the Agar-GUI library.
We bind an action to the button press event, which is called
button-pushed. This event is documented in the
AG_Button(3) manual, and so are the arguments it appends to the list of arguments passed
to the event handler (in this case, a single
The AG_Button API provides a shorthand constructor routine, AG_ButtonNewFn(), which accepts the button-pushed event handler as argument:
The following code fragment is equivalent:
The following code fragment invokes a handler routine artificially:
|AG_EventLoop(3), AG_Intro(3), AG_Object(3), AG_Timer(3), AG_Variable(3)|
|The AG_Event mechanism first appeared in Agar 1.0. The AG_Variable(3) structure was first used to represent event handler arguments in Agar 1.3.4. Agar 1.6.0 added the CONST argument accessor macros and introduced validity and class membership tests for object pointers in event handler arguments. AG_EventCopy(), AG_EventDup() and AG_UnsetEventByPtr() appeared in Agar 1.6.0.|