|
|
|
Re: What is the best way to remove a MToolControl from main toolbar if part is deactivated? [message #1802079 is a reply to message #1802071] |
Thu, 31 January 2019 21:45 |
Thomas Fahrmeyer Messages: 30 Registered: July 2009 Location: Germany |
Member |
|
|
Tom, thanks for the fast replay, as ever ;)
The MToolControl would be added by toolbar.getChildren().add(control). To specify a position I would need to create a toolbarcontribution, correct?
I was not aware that a toolcontrol can have a visibleWhen expression, because the model editor does not provide the possibility to define one. I need to have a look how to create such expression programmatically. Do you have a fast link to some sample code?
How can the active part be injected? The Api of MUIElement takes an instance of an MExpression, but the part injection should be done at lifetime. Ah, I could just define a setter method with @Inject. But as far as I know something like
@Inject
public void setPart(@Active MPart activePart)
is not supported. A hint is appreciated.
What I'm missing (is not a lack of efxclipse) is an Api to provide toolbar and maybe menu contributions context sensitiv to the providing part. It should work in the same way as a local part handler is managed. I think it is not uncommon that a part is providing some stuff to the main toolbar. If the part gets deactivated, these contributions should go away. Do I'm wrong?
Even if the VisibleWhen stuff is working, the toolcontrol is still a child of the toolbar and therefore not garbage collected. If it holds a reference to a big chunk of memory, that is really bad.
The last think: I not fully understood the hint for the addon? Can you elaborate a little bit more?
Thanks for your time and the very good work in efxclipse ;)
Thomas
|
|
|
|
Re: What is the best way to remove a MToolControl from main toolbar if part is deactivated? [message #1802120 is a reply to message #1802105] |
Fri, 01 February 2019 14:38 |
Thomas Fahrmeyer Messages: 30 Registered: July 2009 Location: Germany |
Member |
|
|
I mainly mean that the part is not active. The same semantic as if a command gets disabled because the registered handler is removed.
If a part contributes something relative to its IEclipseContext, I would expect that all that stuff is not active/usable anymore if this part is not active. In my opinion it is not active if anything you mentioned happens.
Let describe my use case: There is a perspective where parts are arranged side by side. One is displaying images another one a PDF file for instance. If the Image Part is active (clicked by the user) every action that is useable by the Image Viewer (like Brightness/Contrast manipulation buttons) is visible in the main toolbar. If the user activates the PDF Part, the Brightness/Contrast Toolbar item should not be visible. That could be done by the mentioned expression. There would be no memory leak because the Image Part still exists. That's fine. But if the the Image part is closed, everything needs to really be removed from the toolbar, otherwise some classes referenced from the toolbar item can not be "garbage collected".
Maybe I'm thinking to complicated, but I like the local handler registration of a part and the management of these handlers very much. I'd like to extend the concept to support toolbar contributions for the any toolbar as well.
Ok, that is not yet possible I would need to do the following:
* define a programmatic MExpression for the MToolControl provided by my part which returns false, if another part is active. That is good for switching to another part
* implement a @PreDestroy method which removes the contribution from the toolbar. The @PreDestroy method is called if part.setToBeRendered(false) is called
Tom, if you maybe can elaborate a little bit more about the lifecycle hook, that would be great.
Thanks
Thomas
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03637 seconds