Is adding a module to the Slicer source code itself the way to go for examples like this? I could imagine a variety of ways that are simpler than building a whole Slicer from scratch.
I don’t know why my code isn’t working, so keeping its build system might be important. Also rewriting it into a copy-paste script would have required a lot of effort. I know that building Slicer is slow, but it does not require much effort. A faster way to test this is to copy-paste added files (and the modified CMakeLists) into existing Slicer instance and rebuilding it.
Load MRHead (so that there is one node that has no attributes)
Load a CT and an RTDOSE from DICOM
Switch to your module
The combobox was not empty and I only saw the CT, which is the expected behaviour. Did I do something in a different order than the way you could reproduce it?
@lassoan You were right about order of widget creation and data loading. Loading data first, and then accessing the widget works (but not the other way around). But I think I tested that - I guess not carefully enough.
@cpinter Do you have some suggestion for currentItemChanged not firing?
I am taking rest of the day off, so I could debug this tomorrow (unless you beat me to it). But it is probably due to some scene change event not being observed, and not in the logic here.
You probably use currentItemChanged wrong. It works in this example. Please look at the differences. As a last resort you can just copy-paste the related code
The only big difference is that in ProstateMRIUSContourPropagation UI is generated programatically, whereas in my MWE it is loaded from a .ui file using QUiLoader.
Hi @dzenanz, sorry for the wait! The cause of the problem was very banal: the signal was not propagated to the combobox (aggregation vs inheritance…). I committed a fix in Slicer. Please let me know how it works.