Thanks Miklos.
Just looking through some code.
Each QmitkRenderWindow has its own slice navigation controller (SNC).
QmitkStdMultiWidget uses the SNC from each render window to send
GeometryTimeEvent, and the time navigation controller (TNC) has a "dummy"
interaction pattern.
QmitkStdMultiWidget calls mitk::RenderingManager::SetTimeNavigationController,
so that the RenderingManager can initialize all the views within
QmitkStdMultiWidget, but this does not allow multiple editors with multiple
QmitkStdMultiWidget, or indeed any other widget with a TNC.
However,
The new mitk::IRenderWindowPart defines GetTimeNavigationController(). The
implication is that each editor has a TNC.
Additionally,
The QmitkAbstractRenderEditor implements GetTimeNavigationController by
retrieving the time navigation controller from the RenderingManager, which for
ExtApp is the QmitkStdMultiWidget TNC, but for third party apps should be a
different one.
So, to my mind, each editor should be able to maintain its own render windows,
either QmitkRenderWindow, or QmitkStdMultiWidget or another class, and conform
to the mitk::IRenderWindowPart interface. Then views such as
QmitkImageNavigatorView for instance would be able to correctly step the axial,
sagittal, and coronal slice by asking for the right render window, and
retrieving the corresponding SNC, and furthermore ask the editor for its TNC
and step through time-steps. This would be a consistent approach for both
QmitkStdMultiWidgetEditor, and any third party editor (eg. ours).
This means that
1. QmitkAbstractRenderEditor should not use the TNC registered with the
RenderingManager, as there may be many editors, and many TNC within an
application, on different Editors/Views.
OR
as each editor takes focus, it should tell the RenderingManager what the
current TNC is. This means that QmitkStdMultiWidget should not do this, but
QmitkStdMultiWidgetEditor should.
2. The mitkRenderingManager can currently only manage one TNC. It should either
manage all of them, "the current one", or none of them - depends on point 1.
3. This has implications for how you "Initialize Views" or do a "global
re-init", as it depends on which TNC you are working with.
Any thoughts? Does my email make sense?
Matt
On 8 Aug 2012, at 17:25, Miklos Espak wrote:
> I overlooked the smart pointer thing. The StdMultiWidget uses smart
> pointer, but the RenderingManager uses an ordinary one. So, when the
> StdMultiWidget is being destructed it deletes the TNC, but a pointer
> remains to it in the RenderingManager.
>
> Why does the StdMultiWidget create a new TNC? Would not it better to
> use the one of the RenderingManager?
>
> Miklos
>
> On Wed, Aug 8, 2012 at 4:42 PM, Miklos Espak <esp...@gmail.com> wrote:
>> Hi Sascha,
>>
>>
>> the problem is that the StdMultiWidget assigns its time navigation
>> controller (TNC) to the RenderingManager.
>>
>> This is a problem if there are more StdMultiWidgets, since the TNC of
>> the RenderingManager will be the TNC of the "youngest" StdMultiWidget.
>>
>> What happens here is that our view contains a StdMultiWidget, and when
>> we close the view then its TNC is destructed but the RenderingManager
>> still has a pointer to it.
>>
>> When a new image is opened, the RM wants to set the input geometry of
>> the TNC that has been destructed meanwhile.
>>
>> I don't see how it can be destructed that early, since it is referred
>> to by smart pointers everywhere (at least I did not like else).
>> Anyway, not the destruction is the main problem here.
>>
>> I added this line to the StdMultiWidget destructor:
>>
>> m_RenderingManager->SetTimeNavigationController(NULL);
>>
>> this fixes the crash, but it might cause other problems later. Could
>> you suggest a better solution?
>>
>> Thanks,
>> Miklos
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
