On Wed, May 30, 2012 at 2:18 PM, Sascha Zelzer <[email protected]> wrote: >> But since there can be only one active render window, it is not a big >> problem. I can fire a deactivation event for the deactivated render >> window part, when a new one is activated. > > The IRenderWindowPartListener interface has been created to make your life > easier, not harder ;-) > > So if your use case is not super-special, it might very well be worth > reconsidering the calling logic for the interface methods.
The use case is simple. I listen to the crosshair position events of the active renderer window. If a new renderer window part becomes active, I add the listener to it, and when it is deactivated, I remove the listener. Now in the RenderWindowPartActivated I have to remove the listener from the previous render window and add it to the new. > If I remember correctly, the initial motivation to not have an Activated -> > Deactivated -> Activated callback chain was to avoid unnecessary > "deactivated" code (for example disabling GUI widgets, removing listeners, > etc.) if there will be an "Activated" event following immediately. I see. I am fine with that I just wanted to know if I can rely on this behaviour. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
