Hi Daniel,
thanks for your reply. Following from this conversation below, I believe
the following change is necessary in mitkToolManager.cpp. At least, this
is what I have been using temporarily, and haven't noticed any strange
side effects.
Please can this be considered as soon as possible?
Thanks
Matt
# git diff Modules/MitkExt/Controllers/mitkToolManager.cpp
diff --git a/Modules/MitkExt/Controllers/mitkToolManager.cpp
b/Modules/MitkExt/Controllers/mitkToolManager.cpp
index 75c7ecc..2349c89 100644
--- a/Modules/MitkExt/Controllers/mitkToolManager.cpp
+++ b/Modules/MitkExt/Controllers/mitkToolManager.cpp
@@ -465,7 +465,10 @@ void mitk::ToolManager::RegisterClient()
void mitk::ToolManager::UnregisterClient()
{
- --m_RegisteredClients;
+ if (m_RegisteredClients > 0)
+ {
+ --m_RegisteredClients;
+ }
if ( m_RegisteredClients == 0 )
{
> On 06/29/2011 06:09 PM, Matt Clarkson wrote:
>
>> However, the current QmitkSegmentationView was working OK. The current
>> QmitkSegmentationView has 3 QmitkToolSelectionBox of tools, but all 3
>> toolboxes register with the same mitk::ToolManager. So, I can load an image,
>> launch the segmentation plugin, and as the plugin is activating, then in
>> QmitkSegmentationView::Activated there are 3 calls, 1 to each toolbox, to
>> enable the toolbox, which internally in
>> QmitkToolSelectionBox::SetGUIEnabledAccordingToToolManagerState() results in
>> 3 calls to the same mitk::ToolManager to
>>
>> m_ToolManager->ActivateTool(-1);
>> m_ToolManager->UnregisterClient();
>>
>> This means that in m_ToolManager, the private member variable
>> m_RegisteredClients will be minus 3.
>>
>> When the reference data is selected, and a segmentation image created, and
>> hence the working data selected, there is a single call to from
>> QmitkToolSelectionBox::OnToolManagerWorkingDataModified() to
>> QmitkToolSelectionBox::SetGUIEnabledAccordingToToolManagerState() which
>> calls m_ToolManager->RegisterClient(), which sets
>> m_ToolManager::m_RegisterdClients to -2. Then when a tool is selected, such
>> as the mitkAddContour tool, in QmitkToolSelectionBox::toolButtonClicked,
>> there is a call to mitk::ToolManager::ActivateTool, which at line 149 adds
>> the tool as a listener, like this:
>> GlobalInteraction::GetInstance()->AddListener( m_ActiveTool );
>>
>> However, this line is only hit because m_RegisteredClients = -2 ???
>>
>> I would imagine this is wrong, because the if statement is only working
>> because the number != 0, and in general, the number of anything should never
>> be negative. In my plugin, as there is only 1 tool box, when the number of
>> Registered clients get set to -1, then when the tool is selected this number
>> goes back up to zero, and then the tool fails to register for events. I
>> would also imagine that the correct fix is in mitkToolManager to make sure
>> that the number of registered listeners of anything can never be negative,
>> and to double check the surrounding logic.
>>
>> Please can this be investigated?
>>
>>
>
> Hi Matt,
>
> I didn't follow all code changes since I wrote this code, but I agree
> that something probably broke the orgiginal intention.
>
> The original implementation had applications in mind, that have multiple
> "functionalities" as in QmitkFunctionality, each of which implements
> some kind of special application module. Several functionalities could
> have differently configured ToolManager instances to provide the most
> appropriate selection of tools to the user.
>
> A main intention of the whole tools implementation was that at any point
> only one tool should be active, i.e. the user (and the developer) knows
> exactly what tool will process user input in render windows.
>
> To allow for this with multiple instances of ToolManager, I had to
> implement something to let application modules (functionalities) tell
> its ToolManager whether or not they are currently "active" (in whatever
> sense the application determines that -- focus or visibility).
>
> The Register/UnregisterClient methods were meant to supports such book
> keeping. Whenever the number of registered clients (application modules)
> would hit 0, the active tool could be unregisted from the interaction
> framework, and when it is increased again, the active tool would be
> activated again. I now regret that I didn't choose unsigned int and did
> not put some asserts into the code.
>
> Places to check for correct implementation would be:
> - QmitkToolSelectionBox (there is probably code that calles
> above functions when the widget is shown/hidden)
> - QmitkSegmentationView.cpp, which will probably also
> register/unregister if the view gets/loses its BlueBerry focus
>
> Unfortunately, I'm unable to check the code myself at the moment, but
> will gladly assist you (or others) in solving this issue.
>
> Regards
> Daniel
>
>
------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
