Home < Documentation < Labs < ModulesAndEvents
This page keeps track of Greg's notes on how to hook up module events
- Getting things working in Slicer can be hairy
- There is not always the right kind of documentation for what you want to do.
- The goal of this page is to take some notes on this process for eventual inclusion in the developer documentation.
- This is intermediate-level documentation
- Scope is limited to C++ development
- MRML nodes are used to store persistent state. You need to use MRML nodes if you want to save and restore slicer scenes.
- MRML nodes can emit events. Logics don't emit events ?
- Either MRML nodes or logic classes can receive events.
- To receive an event, define a function called ProcessMRMLEvents(). This function receives all requested events as an (object, event id) pair. The event id might or might not be unique.
- If I make my own events, how to I ensure they are unique?
- Logic classes implement processes. They serve purposes such as:
- Implement helper logic for widget classes, so that all business logic can be performed without the need of a GUI
- Implement filter-type logic, which manipulates MRML nodes without need for persistent state
- There may be multiple logic classes associated with a single MRML node
- What is the difference between qvtkConnect and qvtkReconnect??
- These should be a serializable copy of the widget state
MRML nodes and multithreading
- Slicer is implemented as a single threaded process
- Therefore, there is no need to implement transaction logic to ensure atomicity when modifying multiple MRML nodes
Best practices for hookup (?)
Between parameter node and widget
- signal from UI element received by module widget
- module widget updates module MRML parameter node (directly, or via module logic) function call
- the widget normally gets modified events from parameter node, and calls updateWidgetFromMRML()
- DisableModifiedEventOn()/Off() can be used to prevent MRML parameter node from emitting modified events back to widget
From observed node (Markup Node) to observing MRML node (Beam Node) and back to widget
- Note: you can observe without referencing and vice versa
- Markup Node fires Modified event (or custom event)
- Beam node receives event in ProcessMRMLEvents()
- Should Nodes receive events or should this be logic
- Beam node fires event using Modified() (or InvokeEvent())
- module logic receives event
- module logic fires event to module widget
- module widget updates UI
- Use blockSignals() to prevent UI element from emitting signals
- module widget updates parameter node (if needed)