3.9. Module Handling

3.9. Module Handling
	Chapter 3. Modules and Networks

3.9.1. Module Context Menu

Right-click modules to open the module context menu. Its contents slightly depend on the module type. Available groups of entries:

Figure 3.10. Module Context Menu

3.9.1.1. Show Window

Figure 3.11. 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 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 it is displayed in a bold font (but only if the field is editable). This makes it easier to see which parameters have been changed for the module.

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. Values of non-editable fields are also shown with an italic font.

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

It is possible to add fields that are not in the C++ code.
It is possible to add field listeners that can trigger script code.
It is possible to keep rarely used fields out of the layouted panel. This way, the panel usability might be enhanced. (Fields can always be edited in the automatic panel.)

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 for scripting in the context of the current module, see Section 4.7.1, “Show Scripting Console”.

3.9.1.2. Instance Name

Edit Instance Name

Figure 3.14. 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 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, since it 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 (paste buffer). This can for example be used to copy the module's name into scripting code.

3.9.1.3. Help

Figure 3.16. Module Context Menu — Show Example Network

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. This creates the initial mhelp file if it does not exist or refreshes an existing mhelp file with updated field information.

3.9.1.4. Extras

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 Inventor modules)

Table 3.36. 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 are an alternative approach to multithreading for utilizing multiple CPUs and 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 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 doesn't 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 sub-modules.
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

Sets all fields whose values differ from their default value to this default value. (This are the fields whose value is displayed in bold font in the automatic panel.)

This is easier than creating a new module to replace an existing module with it.

Set Open Inventor Override Flag (only on Inventor modules)

See Section 27.8, “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 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.5, “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.

3.9.1.5. Reload Definition

Reloads the module definition (.script and optional .py 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 4.3.10, “Preferences — Shortcuts”.

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

3.9.1.6. Related Files

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 (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 files can also be found there.

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

3.9.1.7. Show Enclosing Folder

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

3.9.1.8. Groups

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

3.9.2. Additional Inputs

Modules may have more inputs and outputs than at first visible, to keep the module display as uncluttered as possible. An example for a module with possibly hidden inputs is the View3D module. It offers the additional context menu entry View3D Options → Show Inventor Inputs. If enabled (which is the default), three Inventor input fields are displayed. The option can also be enabled in the Settings panel.

Figure 3.20. View3D With Visible Inventor Inputs (Default)

Figure 3.21. View3D With Hidden Inventor Inputs

	Tip
	The three Inventor inputs of `View3D` have certain positions in the scene rendering, i.e. the first input is before LUT and volume renderer, the second between LUT and volume renderer and the third after LUT and volume renderer. This can be seen when the Inventor inputs are displayed and the internal network is opened, see next paragraph.

Depending on the programming, the number of inputs may be dynamically set. For example, this is the case for the Switch module.

For a supporting visualization while interactively drawing connections, see Section 3.3, “Connector and Connection Types”

3.9.3. Show Internal Network (Macro Modules)

In the context menu of macro modules, the option Show Internal Network is available. If selected, the network of the macro is opened on another network tab.

	Tip
	Refer to chapter Section 4.3.10, “Preferences — Shortcuts” for a shortcut to open a macro's internal network.

Figure 3.22. RegionGrowingMacro — Internal Network

The pseudo-connectors shaded in gray are placeholders and indicate the input (bottom) and output (top) parameters of the macro, which constitute the connectors of the macro module. They are automatically drawn at the edges of the bounding box of the network. Important points about them:

They cannot be moved or removed interactively but can only be changed in the script.
They cannot be selected in a rectangle but each of them can be clicked, in which case the input/output square, the connection(s), and the connected module(s) are highlighted.

Note

Modules in an internal network of a macro that are connected to the macro's input / output fields (visualized by being connected to the pseudo-connectors) cannot be removed interactively from the network.

On an attempt to remove such a module, a window with a warning pops up. If such a module needs to be removed, the according connection needs to be removed in the scripting and the macro reloaded first.

If the macro module only has visible inputs, only those are drawn. An example for inputs only are the View2D and View3D modules.

	Note
	The tab of the internal network remains connected to the module from which it was opened. When the module is deleted or its network closed, the internal network is also closed.