Commands

Definition of a Command

A command is an object that represents the semantic of an activity. "Copy" and "Save" are examples of commands.

Commands can be assigned to control elements e.g. to a ribbon button. The command is triggered when the control element is activated. The command needs to be processed once it has been triggered. Processing is context-sensitive. e.g. the Save command is processed differently in a text window compared to how it is processed in a window which contains an image.

A command is described by an object from the ExtCommand type using the following properties.

Property	Function	Obligatory
Identifier	Unique, string identifier
LabelTitel	Command text
SmallImageSource	Icon, size 16x16
LargeImageSource	Icon, size 32x32
ToolTipText	Tool tip text
ToolTipImageSource	Icon in tool tip

You need to create objects of the ExtCommand type when defining your own commands and register them as a list when editing the OpenModel message using the GUIRegistration.AddCommands method.

Making Assignments to Control Elements

If the create methods of the RibbonManager class are used when creating a control element then the respective command is transferred as an argument to the create methods. The command's data, such as text, images and tool tips, are adopted from the control element.

Processing a Command

Plug-ins can process commands using the class which realizes IApplicationComponent. To do this, the class also has to realize the ICommandDispatchable interface by providing two dispatcher methods:

• CanExeCmd
  Check the command for executability.

• ExecuteCmd
  Executes the command.

A row of dispatcher methods are called from the framework when a command is processed:

• Framework dispatcher for model-independent commands

• Framework dispatcher for model-dependent commands

• Current window dispatcher

• Dispatcher of all components which realize ICommandDispatchable

If a dispatcher processes a command it then returns true as a result and the row is aborted i.e. processing a command from multiple dispatcher methods is never possible at the same time. A plug-in therefore only needs to return true as a result in its dispatcher methods if it processes the command. Processing should not be confused with executability. Processing is given if a command is checked for executability and executed in certain cases. This is a set property that can never be changed. Executability, on the other hand, is a temporary property that depends on the current state of data in the application.

Undo and Redo

Innovator has undo and redo functions. As a rule, these commands relate to individual changing server accesses. One action in the interface by the user can sometimes be realized by means of multiple changing server accesses. A redo only affects the last of these accesses.

Plug-ins often investigate a large set of elements and - if certain conditions are met - make changes to these. Processing often takes place in a loop, which can result in numerous changing server accesses. Following completion of the action, the potential consequences of a redo are not clear. In these cases, it makes sense to delete the undo and redo buffers in order to suppress a redo:

Ino.Model.BeginCommandSequence(commandName);
// Execute action
...

Ino.Model.EndCommandSequence();

The parameter is from the string type and can be selected for the action being completed. This text can be used as a description for describing which action will be suppressed by a redo. The parameter currently has no meaning.

Not all amending server accesses can be canceled. If such changes are in the action in parentheses, then the redo will not work. In such cases it makes sense to delete the undo redo buffer, which will prevent a redo.

// Delete undo/redo buffer
try
{
    Ino.Site.Model.Login.AsExcellence.LoginId.CommandLoggingClearBuffer();
}
catch (Exception ex)
{
    Logger.ExceptionOut(ex);
}