Plug-Ins with No User Interface

Plug-ins with no user interface monitor window messages or evaluate a control file.

A plug-in does not necessarily need to extend the Innovator interface with its own interface elements. There are two use cases where plug-ins work hidden in the background.

Monitoring Messages

The requirement that other actions are carried out automatically when changes are made to the model is conceivable. e.g. once a class has been created, certain standard methods and properties are generated for this class.

Refresh messages are sent when changes are made tot he model. A MessageHandler is needed to check Refresh messages and carry out any further action that may be necessary. MessageHandler is normally linked to a window which only gets messages for tool windows if it is visible. A solution using windows is also not the ideal solution. The IMessageHandable interface can be used to help.

IMessageHandable

The class that realizes IApplicationComponent can also realize the IMessageHandable interface (see IWorkArea). This interface contains a handler for window messages:

void IMessageHandable.MessageHandler(WindowMessage)

The handler contains all messages apart from those that are sent directly to individual windows (Activated, Deactivated, Command).

Note

See the MID.Innovator.Plugin.Sample.HandleMessage sample for using the IMessageHandable interface.

Evaluation of a Control File

The Innovator interface can be started using a control file as call parameter. The control file contains the data needed for logging-in to a model, the respective plug-in responsible for processing the file, and other data. Once you have logged-in to a model, a HandleControlFile message is sent to the plug-in; this can then make further evaluations of the control file. This flow should show documentation generation as an example:

Note

See the MID.Innovator.Plugin.Sample.ControlFile sample for evaluating the control file.

  • The first thing to do is create the control file as XML file. This is the DocuGeneration.xml file in the Sample.ControlFile directory for this example.

    The Repository and Model entries are used for model selection. Login contains information necessary for model login. The role (attribute Role) always needs to be set. The user (User) and a password if set (Password) only need to be entered if the repository server does not use single sign-on.

    The Assembly item sets the plug-in that will process the control file. The entry's value corresponds to the name of the plug-in assembly.

    The SilentMode entry brings about the processing of the control file in 'silent' mode. Error messages are then output in Windows Event Viewer rather than in dialog boxes. The program execution is then terminated. Optionally, a log file with messages can also be output.

    Apart from the login data, the control file can contain any application-dependent data. In this example, the DocuCommand entry gets the data required for documentation generation. A WinWord document is generated for an element and its subelements (recursively).

  • The create control file is transferred to the Innovator interface upon start as parameter.

    innovator.exe "MID.Innovator.controlFile=c:\Innovator\16.0\Plugin Samples\Sample.ControlFile\DocuGeneration.xml"

  • The interface starts and carries out an automatic model login according to the data in the control file.

  • Once you have logged-in, a HandleControlFile message is sent to all specified plug-ins. The control file's path is contained in the message's data..

  • The plug-in can read the control file, evaluate application-dependent data and run the action accordingly.