Figure 3.11. Module Context Menu — Show Window

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

	Tip
	Refer to chapter Section 4.3.10, “Preferences — Shortcuts” for a shortcut for opening a module's automatic panel.

Figure 3.12. Automatic Panel

The automatic panel lists all fields of the module in order of their initialization in the C++ code or of their definition in the Macro definition. 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.

If a field has a value different from the default value of the field for that module, the Flags column will have a ! entry. You can sort by the Flags column to see all fields with a changed value more easily.

	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.

Typically, another type of panel is also available, which displays the parameter fields in a structured layout and is written in MDL.

Important points:

Figure 3.13. 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”.

Show Scripting Console

Opens the Scripting Console with the context of the current module, allowing, for example, ctx.field("fieldName") calls to reference and access fields belonging to that module, see Section 4.7.1, “Show Scripting Console”.

Edit Instance Name

Figure 3.14. Module Context Menu — Edit Instance Name

This option allows distinguishing between several instances of the same module. Within a network, each module instance must have a unique name. If no specific instance name is provided, copies of the modules are automatically numbered (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 Section 4.3.10, “Preferences — Shortcuts”) to open a dialog for entering a new instance name.

The instance name is displayed above the module name. If the instance name is the module name plus a number, only the instance name is displayed, as it already includes the module name.

Figure 3.15. Modules and Instance Names

Copy Instance Name

This option copies the module's instance name to the system's clipboard. This can, for example, be used to copy the module's name into scripting code.

Figure 3.16. Module Context Menu — Show Example Network

Show Example Network

Opens the example network in a new network tab. This option is 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, displaying the number of example networks. Upon selection, a submenu offers all available example networks by their names.

Show Help

Displays the HTML help file for the module in the default browser. This option is only active if a help file exists.

Edit Help

Edits the mhelp file in MATE. Use this option if fields have changed (renamed, new, or removed) or if the module is new. This creates the initial mhelp file if it does not exist or refreshes an existing mhelp file with updated field information.

Show DLL Dependency (not on macro modules)

This option uses (on Windows) the Dependency Walker for checking and displaying all dependencies for the module. For more information, please refer to the help of the Dependency Walker. Linux has its own solution for displaying similar information.

Figure 3.17. Dependency Walker

Run In Separate Process (not on Open Inventor modules)

Table 3.37. Run In Separate Process

MeVisLab allows for running ML and macro modules in background processes, so-called worker processes. We call the underlying concept Remote Modules. “Run In Separate Process” will replace the selected module in the network by a remote module and start a MeVisLab worker process that loads the replaced module. Field and image changes are transmitted asynchronously between MeVisLab and the worker process.

Remote Modules offer an alternative approach to multithreading for utilizing multiple CPUs and enabling asynchronous processing. For example, a remote module can be used to move long-running calculations into the background to keep the GUI responsive.

Note

Restrictions: You can only move a single module. Open Inventor modules cannot be moved to a worker process. Image inputs are not supported. It is not worth loading an image in the main process and then transferring the image data to the worker process. Instead, load it directly in the worker process; you may need to create a macro module for this. Image outputs do not support image extension information, but this is typically unnecessary. Base fields are only supported through special handlers. Currently, there are only handlers for XMarkerList(Container) and some specialized remote Base types like RemoteRendering, RemoteFileTransfer, RemoteCallInterface, and AbstractItemModel. Other Base types will result in an empty Base field. Scripting does not work if it accesses the GUI or is called from the GUI (since the GUI lives in another process than the scripting context). Controls may also not use fields of submodules. 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 updates are transmitted asynchronously.

Restore Default Values

Resets all fields whose values differ from their default value back to the default value. (These are the fields with an ! entry in the Flags column in the automatic panel.)

Set Open Inventor Override Flag (only on Open Inventor modules)

See Section 28.7, “Set Open Inventor Override Flag (Inventor Modules)”.

Tests

Figure 3.18. Module Context Menu — Tests

In the Tests submenu, testing options are available.

Run All

Starts all available tests for the module. In the case of Threshold, the generic test case “Formal” and the “Functional” test case are executed. When the tests are finished, a test report window is opened. (See also Section 4.6.6, “Run Module Tests...”, the TestCenter Reference, and the Getting Started, chapter 16, “Using the TestCenter”.)

Edit <AssociatedTest>

Opens the files of a test associated with the selected module.

Create Tests

Opens the TestCaseManager on the tab to create a new functional test.

Reloads the module's definition (.script and optional .py file). This is necessary when laying out 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 4.3.10, “Preferences — Shortcuts”.

If modules are being reloaded, an animation (modules turn white and slowing gain their color back) indicates that the modules' definitions have indeed been reloaded.

Figure 3.19. Module Context Menu — Related Files

Related Files: Lists all files belonging to the module. Possible file types are .def/.script (MDL definition files), and .py (Python 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 that contains the .def and .script files. If the module is augmented by scripting, the .py files can also be found there.

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

Shows the directory where the definition file of the module is located.

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