Windows Filter and Command Handler Anatomy

Visual LANSA Framework

Windows Filter and Command Handler Anatomy

Applies to: WINDOWS only.

WINDOWS filters and command handlers:

  • Are used for all Windows applications.
  • Are usually visual in nature
  • Can have their forms painted by using the normal Visual LANSA form painter (i.e.: use the Design tab when reviewing the source code for the filter or command handler in the Visual LANSA editor).
  • Execute on the client system
  • Can maintain their state because they are Windows based. 

Structurally WINDOWS filters or command handlers look like this:

 

There are several important parts in any filter or command handler:

All filters and command handlers extend (i.e.: inherit from) a base class shipped with the Framework. Filters extend a class named #VF_AC007 and command handlers extend a class named #VF_AC010. In both cases the base classes provide a set of pre-defined behavior to the command handler or filter.

All filters and command handlers can have an optional method named uInitialize that is executed just once when the filter or command handler is being created. Typically you use this to fill in details on the form that the filter or command handler will display.

All filters and command handlers can have an optional method named uTerminate that is executed just once when the filter or command handler is being destroyed. Typically you use this to free up things that the filter or command handler uses.

Command handlers normally have a uExecute method. This method is invoked whenever the user executes the Framework command that is associated with the command handler. Filters do not have uExecute methods because there is no command associated with them. They simply display their user interface and then wait for the user to indicate what they want to do (eg: Click the Search button).

Command handlers can have an optional method named uActivate that executes when the user causes the command handler to be redisplayed (ie: activated). Typically when switching back to a command handler from another business object – but they did not execute the command. Use of this method is quite rare and very specialized. Make sure you understand its purpose and invocation timing before using.

Most filters and command handlers also have their own unique event handling routines (EvtRoutine/EndRoutine command pairs) and methods MthRoutine (Mthroutine/EndRoutine) command pairs. This example shows "Click" event routines for two buttons named  #Save_Button and #Transfer_Button. The logic inside these routines would define what happens when the respective buttons are clicked by the user.

Writing WINDOWS filters or command handlers is just like writing any other Visual LANSA reusable visual part, except that the Framework manages how, when and where your filter or command handler is created.