Figure 3.21. Module Context Menu — Show Window

Each module has at least one panel, the automatic panel which is a list of all fields and parameters of the module. Use it for an overview or for editing the parameters (see also Section 10.1, “Fields”).

	Tip
	Refer to chapter Section 25.3, “Module and Network Handling — Shortcuts and Tricks (All Platforms)” for a shortcut for opening a module's automatic panel.

Figure 3.22. Automatic Panel

The automatic panel lists all fields of the module in order of their initialization in the C++ code. It also shows the data type of the field, whether it is an input or output field, and its current value. The value can be edited directly on the automatic panel.

Tip

The header of the list of fields of the automatic panel has a context menu where you can toggle how to sort the fields or to turn off the sorting at all. In the later case, the fields are ordered as they are implemented in C++ or in the script. An option 'Show Attribute Column' turns on an otherwise hidden column where non-persistent and non-editable fields are marked with 'p-' and 'e-', respectively.

Typically, another type of panel is also available, which shows the parameter fields in a layouted style. It is written in MDL. Important points:

Figure 3.23. Panel Defined in MDL

Other windows may be available. For example, for the View2D module, a Viewer and a Settings window are available. For information on defining windows, see the MDL Reference, chapter “1.3.2.1. Window”. For an example, see the Getting Started, chapter “Adding the Macro Parameters and Panel”.

Figure 3.24. Module Context Menu — Edit Instance Name

This option allows distinguishing several instances of the same module. Within a network, each module instance must have a unique name. If no specific instance name is given, the copies of the modules are numbered automatically (1, 2, 3, etc.). Alternatively, the instance can be renamed manually.

	Note
	Instances of modules have to be unique because modules are addressed by their instance names in scripting.

Select the option or use the respective shortcut (see Chapter 25, Shortcuts) to open a dialog for entering a new instance name.

The instance name is displayed above the module name. If the module instances are numbered, only the instance name is displayed, since it includes the module name.

Figure 3.25. Modules and Instance Names

Run In Separate Process

This is an experimental feature which allows moving ML and macro modules to a worker instance of MeVisLab that is automatically started in the background. Field and image changes are transmitted asynchronously between the main instance and the worker instance. This feature can be used to move long running calculations into the background without blocking the GUI, for example.

Figure 3.26. Run In Separate Process

Note

Restrictions: You can only move single modules. Image inputs are not supported. It is not worth to load an image in the main process and then move the image data to the worker process. Load it directly in the worker process instead; you might need to create a macro module for this. Image outputs do not support image extension information. Normally you don't need this. Base fields are only supported through special handlers. At the moment there are only handlers for XMarkerList(Container) and some specialized remote Base types like RemoteRendering, RemoteFileTransfer, RemoteCallInterface and AbstractItemModel. Other Base types will just result in an empty Base field. Inventor nodes do not work. Scripting may not work if it accesses internal fields of a macro module from the GUI or tries to change the GUI from a module field listener (you can define field listeners on the GUI for that). Use an ItemModelView instead of a ListView if you need to display lists or tables in your GUI. Module fields will not update immediately after some other field was changed, since these are transmitted asynchronously.

Figure 3.27. Module Context Menu — Help

Show Example Network

Opens the example network in a new network tab. Only active if an example network exists (otherwise the entry is grayed out).

If a module has multiple example networks, this entry is a menu item, showing the number of example networks. On selecting, a subnetwork offers all available example networks by their names.

Show Help

Displays the HTML help file for the module in the default browser. Only active if a help file exists.

Edit Help

Edits the mhelp file in MATE. Use this option if fields have changed (renamed, new fields, removed fields) or if the module is new.

Reloads the module definition (.def file). This is necessary when layouting panels and windows or when working on the scripting.

	Tip
	A single selected module can also be reloaded by pressing the according shortcut key for the OS. Refer to Section 25.1, “Shortcuts on Windows and Linux” and Section 25.2, “Shortcuts on Mac OS X”.

If modules are being reloaded, an animation (module turns white and slowing gains its color back) indicates that the modules' definitions are indeed being reloaded.

Figure 3.28. Module Context Menu — Debugging

In the Debugging submenu, helpful options are available.

Show Scripting Console

Opens the Scripting Console for scripting in the context of the current module, see Section 19.1, “Scripting”.

Run Tests

Starts the TestCenter for the module. Test cases associated with the module(s) are listed here. In case of WEMIsoSurface, only the two generic test cases “Formal” and “Meta” associated with all modules are available. When Finish is clicked, the test cases are run and test reports are available. (See also Section 4.6.4, “Run Module Tests”, the TestCenter Reference, and the Getting Started, chapter 16, “Using the TestCenter”.)

Figure 3.29. Run Tests — Test Selection

Figure 3.30. Run Module Tests — Reports

Show DLL Dependency (Windows only; not for macro modules)

This option uses the Dependency Walker for checking and displaying all dependencies for the module. For more information, please refer to the help of the Dependency Walker.

Figure 3.31. Show DLL Dependency

Figure 3.32. Module Context Menu — Related Files

Related Files: Lists all files belonging to the module. Possible file types are .def/.script (MDL definition files), .vcxproj (VC++ project files on Windows), and .py / .js (scripting files). Select a file to open it in the default editor (as set in Section 4.3.4, “Preferences — Supportive Programs”).

Show Definition Folder: Opens the definition folder of the module which contains the .def and the .script file. If the module is augmented by scripting, the .py or .js files can also be found there.

Show Source Folder: Opens the folder containing the source code files of the module.

For the Groups functions, see Section 3.9, “Using Groups”.

Adds the selected module(s) to the Snippet List, see Chapter 22, Snippets List.