The validation of MDL files is done with an MDL validator.

Excerpt of the validator for the general module definition:

Group _Module {
  allowTags  {
    comment        = STRING
    author         = AUTHORS
    exampleNetwork = MLABFILE
    ...
  }
  allowChildren  {
    Interface   = ""
    Commands    = ""
    Description = ""
    ...
  }
}

The validators of the specific module types then relate to the general module definition.

Group MLModule {
  value = NAME
  allow = _Module     <- allowed groups  
  allowTags {         <- allowed tags (make sure to use the right data types) 
    class = STRING           
    DLL   = DLLNAME           
  } 
} 

Group InventorModule {
  value = NAME 
  allow = _Module 
  allowTags {
    class          = STRING
    hasGroupInputs = BOOL
    hasViewer      = BOOL
    ...
  }
}

For other validators like for fields, panels, etc., the principles work accordingly.

Usually, a developer does not have to deal with the validator aspect of the MDL. However, once a new control is to be implemented, a validator should be written for that to avoid error messages, see Section 11.3.3, “Creating Custom MDL Controls”.

An important effect of the Model-view-controller pattern is the separation of the interfaces (as fields) and the actual controls defined in the windows section of an modules GUI definition.

The fields defined in the interface sections are the models.

Figure 11.2. Fields as Model

The controls in the GUI are the view and also the controller.

Figure 11.3. Controls as View/Controller

For a set of fields/models, many different views can be built.

Figure 11.4. Controls as Views/Controller

It is important to keep this Model-view-control design in mind, otherwise it is easy to mix up the definition of fields (Interface section) with the GUI control of the field (Window section).

	Note
	Admittedly, it's a bit misleading that the Field is also used in the Window section for the field controls.

From the point of view of the MDL controls, the View3D panel looks like this:

Figure 11.5. View3D Panel with C++ Class Names of Included MDL Controls for Scripting

The GUI definition of a module is written into the .script file of a module.

The Interface section is foremost used for Macro modules to declare fields. It is also used to declare extra fields of C++ modules or fields that should be kept persistent:

The fields defined here may also forward existing fields of sub modules (internal fields) instead of defining new ones.

Declaring parameter fields of a C++ module has the advantage that these fields can be made persistent to save their values along with the network. (Normally, internal module states are not saved when the network is saved.)

The Description section is optional and can be used for all module types. It contains definitions for:

The Commands section is used to add Python script files and commands. (For details of the module initialization, see MDL Reference, chapter “Commands”.)

The Window section allows defining the GUI for the available Interface elements. The possible controls can be split into the following groups:

See the MDL Reference for a complete list of available controls.

The number of Window sections — which is the number of panels for a module — is unlimited. See View3D as an example for multiple panels.

“Field” has two meanings in MeVisLab:

In scripting these objects have different class names:

Fields from a Scripting Perspective

Fields can be accessed from scripting. Take this integer field as an example:

Interface {
   Parameters {
    Field intFieldName { type = Int }
  }
}

Getting and setting the value:

ctx.field("intFieldName").value = 13

Getting and setting the value as a string (typically used for serialization purposes):

ctx.field("intFieldName").stringValue = "13"

To force notification of all field listeners:

ctx.field("intFieldName").touch()

FieldListener

The FieldListener binds scripting commands to a field. The command will always be called when the field issues a notification to its listeners.

	Note
	There is an important difference between FieldListeners defined in the Commands section and the ones defined in the Window section: The former is created when the module is created, and thus is always available. The latter is only created when the window is created, and it is destroyed when the window is destroyed. This will be explaind in the examples below.

Example:

// triggerButton Field is already defined in Interface/Parameter
Interface {
  Parameters {
    Field triggerButton { type = Trigger }
  }
}

Commands {
  source = $(LOCAL)/ExampleToggleButton.py
  FieldListener triggerButton { command = callGlobal }
} 

Touching the trigger field in Python will cause a notification and the field listener will call the given command, which is “callGlobal” in this example:

ctx.field("triggerButton").touch()

When “callGlobal” is called, there is no association to a window. The current window ID is 0, which means there is no current window. This means if you call ctx.control("controlName") in it, then MeVisLab will print an error that it cannot find the control.

If the field listener is defined inside of a window, it is only active when the window is actually created.

Window {
  Category {
    FieldListener triggerButton { command = callLocal }
  }
}

When “callLocal” is called, the current window ID is set to the window in which the field listener is defined. Calling ctx.control("controlName") in it will look inside this window for the control. This also means, that control names must only be unique inside a window, and can be reused in multiple windows of the same module.

Figure 11.6. Command Execution Context

Accessing Controls from the Scripting Console

From the scripting console, looking up a control only works when the correct context is set. First, the module context must be right. The scripting console must be opened from the context menu of a module to have it as the current context. The scripting console that can be opened from the Scripting → Show Scripting Console menu has the current network and not the selected module as context. Second, the window ID is 0 by default. To look up a control the window ID must be set accordingly. For debugging purposes, the function ctx.controlDebug("controlName") can be used in the scripting console as an alternative to setting the current window ID. It looks for the control in all open windows.

The following figure demonstrates that the global scripting console is not associated to a selected module in the network. Although the panel of the TestListBox module is open, the control cannot be found. It can be found in the scripting console of the module itself.

Figure 11.7. Contexts of the Scripting Console