Is your feature request related to a problem? Please describe.
After a scripted module is reloaded, the incorrect virtual functions (e.g. enter()) are called, while a workaround was integrated through #7351, a more robust approach is needed.
The root cause of this issue is that each C++ instance of a scripted module maintains a reference to a qSlicerPythonCppAPI instance through the d->PythonCppAPI internal variable. When virtual functions are invoked from Python (for instance, when the module manager calls qSlicerAbstractModuleWidget::enter()), the previous reference handles are still utilized.
Describe the solution you'd like
To comprehensively resolve this, we should implement a systematic solution by introducing a "reload()" function at the C++ level. This function will ensure that the underlying PythonCppAPI object is updated correctly. To prevent any potential "catch 22" scenarios, the reload API should be accessible via the module manager.
Describe alternatives you've considered
NA
Additional context
Is your feature request related to a problem? Please describe.
After a scripted module is reloaded, the incorrect virtual functions (e.g.
enter()) are called, while a workaround was integrated through #7351, a more robust approach is needed.The root cause of this issue is that each C++ instance of a scripted module maintains a reference to a
qSlicerPythonCppAPIinstance through thed->PythonCppAPIinternal variable. When virtual functions are invoked from Python (for instance, when the module manager callsqSlicerAbstractModuleWidget::enter()), the previous reference handles are still utilized.Describe the solution you'd like
To comprehensively resolve this, we should implement a systematic solution by introducing a "reload()" function at the C++ level. This function will ensure that the underlying
PythonCppAPIobject is updated correctly. To prevent any potential "catch 22" scenarios, the reload API should be accessible via the module manager.Describe alternatives you've considered
NA
Additional context