Persistate

User Interface classes

Hide Navigation Pane

User Interface classes

Previous topic Next topic No directory for this topic  

User Interface classes

Previous topic Next topic Topic directory requires JavaScript JavaScript is required for the print function Mail us feedback on this topic!  

Future Enhancement

Although the separation between controller and user interface is entirely format and proscribed in Persistate, as yet only a Windows Forms based Desktop User Interface has been implemented.  Further types of user interface will be implemented in future versions.  For now this section considers the desktop UI only.

Persistate generates two types of class for the desktop UI.  Firstly it generates one class for each Layout that you create.  This is somewhat different from the generation of classes in the Model and Controller, in that these UI classes are not generated from objects specified in the definition file.  Rather they are generated from the Layouts you create using the Persistate Generator application, either manually one at a time, or using the Generate default layouts operation.

These generated classes are forms and grids which portray the objects defined in the Model.  They all derive from the PContainer class, which itself derives from UserControl.  They are generated in the same format as those generated by Visual Studio's visual form designer, so you can open them in Visual Studio and refine them, changing properties as necessary and even adding controls manually.  Persistate retains your changes if you regenerate the control from the Layout.  See Developing the user interface for more details.

The second type of class generated for the desktop UI controls the "presence" of your package's operations in the user interface.  This presence consists of a value indicating whether the operation should be enabled, disabled or invisible, and a tooltip text, which can be different for enabled and disabled operations.  The presence methods are called by the Persistate run-time on the Application.Idle event, and on menu drop down or pop up, and are passed the currently selected target object and collection, so you can make presence decisions based on that.

These generated classes mirror the generated classes in the Controller module, in that there is one class generated per operation group. and within each class, one method per operation in the group.  The class name is identical to the Controller class, i.e. <operation group name>Operations, and the methods are called <operation name>Presence.  If an operation is defined as a user interface operation, then its execute method will also be in this class alongside its presence method.  See The ActionOperations desktop UI class for an example generated class.