vtkMRMLSubjectHierarchyNode causes Slicer to crash during surgical plan

Support
1

Hi. Thank you for the hardwork on Slicer development!

I have developed a very nice feature I would like to integrate to the main branch of GitHub - SlicerIGT/SlicerBoneReconstructionPlanner: 3D Slicer module for planning mandible reconstruction surgery using fibula flap

This module handles tens of objects in a handful of folders that are created and deleted during the workflow. Till now it was stable enough. But now it is not, one folder with lots of items and subfolders is not visible on the subject hierarchie till I press right click on some folder visibility button, then it appears but Slicer shows the processing mouse cursor animation and then it crashes (sometimes). Other times it crashes when I start processing but not reliably (this involves creation and deletion of folders).

Hope you can help.

Mauro

2

Which Slicer versions do you mean by “till now” and “now”?

To investigate, we need to be able to reproduce the issue. Ideally, a script that we can copy-paste into the Python console.

1 Like
3

Hi

I mean today’s preview release by “now” and “till now”.

To investigate, we need to be able to reproduce the issue. Ideally, a script that we can copy-paste into the Python console.

On a virtual surgical plan, BRP creates the hierarchy below when clicking the “Update fibula planes over the fibula line, bone pieces and transform them to the mandible” button:

BoneReconstructionPlanner/
  Mandible reconstruction/
    LotsOfNodesAndSubfolders 
 Inverse mandible reconstruction/  <-- this folder visibility is set to hidden while creating it
    LotsOfNodesAndSubfolders

There are two problems with the image below:

    1. The “Inverse mandible reconstruction” folder doesn’t appear on the qMRMLSubjectHierarchyTreeView although it has been created.
    1. The orange mandible that appears over the fibula on the lower 3D view is inside the “Inverse mandible reconstruction” folder (and it should be hidden because its parent folder is hidden)
      Screenshot from 2022-10-25 10-03-55
      Screenshot from 2022-10-25 10-03-551920Ă—1080 181 KB

When I click the eye icon on qMRMLSubjectHierarchyTreeView of “Mandible reconstruction” the “Inverse mandible reconstruction” folder appears:

Screenshot from 2022-10-25 10-04-14
Screenshot from 2022-10-25 10-04-141920Ă—1080 179 KB

If I click on the eye icon of the “Inverse mandible reconstruction” folder (once or twice) Slicer crashes.

Here is a Slicer scene where you can quickly make Slicer crash:
https://1drv.ms/u/s!AgpRvclrLSCegWlpmdL1L8s9BXrg?e=1btqGb

You need to install BoneReconstructionPlanner extension, then in “application settings”->“modules” replace the BRP folder path by the module path inside this branch of BRP, load the scene I provided, switch to BoneReconstructionPlanner module and do the button-clicks I explained at the beginning.

Thank you, hope you can help

4

The solution was simple though, just replace the last line of this:

      inverseMandibleReconstructionFolder = shNode.CreateFolderItem(parentItemID,"Inverse mandible reconstruction")
      pluginHandler = slicer.qSlicerSubjectHierarchyPluginHandler().instance()
      folderPlugin = pluginHandler.pluginByName("Folder")
      folderPlugin.setDisplayVisibility(inverseMandibleReconstructionFolder, 0)

by this:

      qt.QTimer.singleShot(0, lambda: folderPlugin.setDisplayVisibility(inverseMandibleReconstructionFolder, 0))

May be it should be clarified here that you should use a timer if you are not on the python console (for more context see this link).

5

There is a useful bug:

If you delete and create a folder with the same name Slicer remembers if it was visible or not before you would have deleted it

This is useful for BRP because you can select on the treeview if you want to see the folder of “Mandible reconstruction” or “Inverse mandible reconstruction” and then after updating the virtual surgical plan it doesn’t autotoggle back to “Mandible reconstruction” folder

6

It should be safe to call folderPlugin.setDisplayVisibility(inverseMandibleReconstructionFolder, 0) right after creating the folder. I could not reproduce any issue with calling this method immediately.

Would you be able to come up with a minimal example that demonstrates how calling setDisplayVisibility immediately causes any issue?