Fields can still use external values as field values. This concept was implemented in the first ML version to make it easier to port modules from the old ImgLab application. However, using such references typically makes module programming more difficult than using the fields contents as values. The normal way to port such code is to remove the externally referenced values/members and to replace every occurrence of the value/member by field->getValue() calls or field->setValue() calls. Be careful when using field->setValue() calls because the setting of a value normally also notifies attached fields of that value change.

You may sometimes find modules where field names start with capital letters or underscores, or where field names contain spaces, commas or other non-alphanumeric characters. Some of these field names are/were no error; however, they are not up to date anymore and can cause problems. Normally, a field should start with a lowercase letter and it should contain alphanumeric characters only. This makes module scripting (e.g., in applications such as MeVisLab) much easier and more reliable. Also, field names should be very similar to the names of the member variables managing those fields in the module code.

Older modules often use a flag to suppress calls of the handleNotification() method in the module while field values are initialized in the constructor or changed elsewhere. The more reliable way is to use handleNotificationOff() and handleNotificationOn() which does not need additional code in handleNotification() or a flag member in the module. Also see Section 3.1.2, “Implementing the Constructor” for more information.

Older modules often use cout, cerr or std::cout, std::cerr, printf or fprintf calls for debugging or error handling purposes. The same is also true for exit(), abort() or assert() statements. This is not desired in module programming because programmers tend to forget to remove such calls, i.e., they will forever print information to the output streams, or the error will not reach the central error handler of the ML. Replace those calls by mlDebug macros as described in Section 5.1, “Printing Debug Information” or by the corresponding error handling macros as described in Section 5.2, “Handling Errors”. The debug macros can also remain in the code and can be selectively enabled or disabled during runtime.