I am working a module that relies heavily on the subject hierarchy. I need to listen to its modified/added and removed item events. Here is an abstract of what I do:
This crashes on Slicer that I built manually.
The issues comes from theEndModify() that will re-invoke all the custom events. Those events however are invoked without a calldata and that makes the application crash when it tries to convert the calldata to long.
I am not sure what can be done for this. The naive solution I see would be to never use the calldata to answer the callback of the subject hierarchy. But then we would need a method on the subject hierarchy node to know what was the item ID that was last modified ?
Or should the VTK python command handle the case where the calldata is NULL better ?
@lassoan, @cpinter:
I am thinking to implement a method that stores the ID of the last modified item so it’s always accessible through python. Since you implemented this node, I was wondering what you were thinking ?
After talking with @lassoan, the current mechanism is generic and can handle any event. As you first suggested, we should instead fix the VTK wrapping layer to that the call data is None if the pointer is null.
From the application perspective, this would mean that we can’t know the specific ID or name or … that was modified and the UI should be refreshed.
Thanks @jcfr and @lassoan for helping Johan! I just managed to dig through the administrative stuff and get back to real work after I got back from my long trip.
I have been thinking about this as well, but haven’t made this change, because trying to find a non-existent item is an operation that probably leads to errors, so logging an error can be useful.
I think instead of making this fail silently you could investigate why these operations want to access this non-existent item.
We simply ignore any event passed with NULL calldata. Users will have to be careful when using batch updated with the Subject Hierachy Node and call ItemModified() themselves if needed.
We could re-implement vtkMRMLNode::InvokeCustomModifiedEvent and vtkMRMLNode::InvokePendingModifiedEvent in the Subject Hierarchy node to handle passing the item ID
I don’t feel that any of these are ideal, so feel free to suggest other ideas !
Normally, any custom modified events with NULL calldata means that multiple updates happened, so a full update is needed. Therefore, for me the obvious solution is to handle this as a full update.
Batch processing is always has overhead, so it should only be used if either A. it is important to not invoke (custom) modified events before multiple modifications are completed; or B. to improve performance by replacing many small updates by one big update. If you find that You may decide to call Start/EndModify only when many items are modified (similarly how it is done here, when batch processing mode is used only when more than a few models had to be updated).