Home » Modeling » GMF (Graphical Modeling Framework) » workaround for bug #147855 (hide compartment if empty) - any hints?
| |
Re: workaround for bug #147855 (hide compartment if empty) - any hints? [message #15963 is a reply to message #15898] |
Fri, 11 August 2006 12:56   |
Eclipse User |
|
|
|
Hi ;
Few points to consider:
1- the fact that you got an exception while setting the view visibility,
means that there is no write transaction open
here is a quick sample that shows how to do it :
final View view = getNotationView();
final SetPropertyCommand cmd = new SetPropertyCommand(getEditingDomain(),
new EObjectAdapter(view),
PackageUtil.getID(NotationPackage.eINSTANCE.getView_Visible( )),
DiagramUIMessages.Command_hideLabel_Label,
Boolean.valueOf(view.getChildren().size()>0));
Map options = null;
options =
Collections.singletonMap(Transaction.OPTION_UNPROTECTED,
Boolean.TRUE);
AbstractEMFOperation operation = new AbstractEMFOperation(
getEditingDomain(),
StringStatics.BLANK, options) {
protected IStatus doExecute(IProgressMonitor monitor,
IAdaptable info)
throws ExecutionException {
cmd.execute(null,null);
return Status.OK_STATUS;
}
};
try {
operation.execute(new NullProgressMonitor(), null);
} catch (ExecutionException e) {
int i = 0 ;
i++;
}
2- you have to be careful about setting the view visibility to False,
because as soon as you set it to false the edit part till be removed
completely. This means you will not be able to use the tool to create
the children any more, and you have to provide a different way to do that
Matthias Köster wrote:
> Hi Michael,
>
> As a workaround i've overriden the
> ListCompartmentEditPart.refreshVisibility method:
>
> protected void refreshVisibility() {
> final View notationView = getNotationView();
> final boolean hasChildren = notationView .getChildren().size() > 0;
> setVisibility(hasChildren);
> }
>
> This just changes the visibility of the edit part and not of the view.
> But when i changed the view visibility i got some transaction related
> exceptions! Perhaps someone has a better solution?
>
> You also have to call this method if a children is added or removed,
> this can be done by overriding the notifyChanged method of your
> comparment edit part.
>
> Matthias
>
> Michael Haeberlen wrote:
>> Hello,
>>
>> I'm looking for a workaround for
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=147855
>> Does anyone has an idea how to make this working?
>>
>> Any hint is highly appreciated
>>
>> Michael
|
|
|
Re: workaround for bug #147855 (hide compartment if empty) - any hints? [message #17015 is a reply to message #15963] |
Mon, 14 August 2006 03:45   |
Eclipse User |
|
|
|
Hi Mohammed,
So that means it's better to stick with my solution of just hiding the
edit part? Or is it better to hide the view too?
Matthias
Mohammed Mostafa wrote:
> Hi ;
> Few points to consider:
> 1- the fact that you got an exception while setting the view visibility,
> means that there is no write transaction open
> here is a quick sample that shows how to do it :
>
> final View view = getNotationView();
> final SetPropertyCommand cmd = new
> SetPropertyCommand(getEditingDomain(),
> new EObjectAdapter(view),
>
> PackageUtil.getID(NotationPackage.eINSTANCE.getView_Visible( )),
> DiagramUIMessages.Command_hideLabel_Label,
> Boolean.valueOf(view.getChildren().size()>0));
>
> Map options = null;
> options =
> Collections.singletonMap(Transaction.OPTION_UNPROTECTED,
> Boolean.TRUE);
>
> AbstractEMFOperation operation = new AbstractEMFOperation(
> getEditingDomain(),
> StringStatics.BLANK, options) {
>
> protected IStatus doExecute(IProgressMonitor monitor,
> IAdaptable info)
> throws ExecutionException {
>
> cmd.execute(null,null);
>
> return Status.OK_STATUS;
> }
> };
> try {
> operation.execute(new NullProgressMonitor(), null);
> } catch (ExecutionException e) {
> int i = 0 ;
> i++;
> }
>
> 2- you have to be careful about setting the view visibility to False,
> because as soon as you set it to false the edit part till be removed
> completely. This means you will not be able to use the tool to create
> the children any more, and you have to provide a different way to do that
>
>
>
>
> Matthias Köster wrote:
>
>
>> Hi Michael,
>>
>> As a workaround i've overriden the
>> ListCompartmentEditPart.refreshVisibility method:
>>
>> protected void refreshVisibility() {
>> final View notationView = getNotationView();
>> final boolean hasChildren = notationView .getChildren().size() > 0;
>> setVisibility(hasChildren); }
>>
>> This just changes the visibility of the edit part and not of the view.
>> But when i changed the view visibility i got some transaction related
>> exceptions! Perhaps someone has a better solution?
>>
>> You also have to call this method if a children is added or removed,
>> this can be done by overriding the notifyChanged method of your
>> comparment edit part.
>>
>> Matthias
>>
>> Michael Haeberlen wrote:
>>
>>> Hello,
>>>
>>> I'm looking for a workaround for
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=147855
>>> Does anyone has an idea how to make this working?
>>>
>>> Any hint is highly appreciated
>>>
>>> Michael
|
|
|
Re: workaround for bug #147855 (hide compartment if empty) - any hints? [message #17275 is a reply to message #17015] |
Mon, 14 August 2006 10:09  |
Eclipse User |
|
|
|
Hi Matthias,
setting the visibility on the figure Vs the view depends on your use case.
Setting the view visibility to false is better from the memory
consumption point of view but it require providing a way for creating
elements inside the invisible compartments.
I'd say if memory consumption is a concern (i mean if your diagrams are
big and contain lots of elements on them) then setting the visibility on
the view is better otherwise setting it on the figure will be OK.
Matthias Köster wrote:
> Hi Mohammed,
>
> So that means it's better to stick with my solution of just hiding the
> edit part? Or is it better to hide the view too?
>
> Matthias
>
> Mohammed Mostafa wrote:
>> Hi ;
>> Few points to consider:
>> 1- the fact that you got an exception while setting the view
>> visibility, means that there is no write transaction open
>> here is a quick sample that shows how to do it :
>>
>> final View view = getNotationView();
>> final SetPropertyCommand cmd = new
>> SetPropertyCommand(getEditingDomain(),
>> new EObjectAdapter(view),
>>
>> PackageUtil.getID(NotationPackage.eINSTANCE.getView_Visible( )),
>> DiagramUIMessages.Command_hideLabel_Label,
>> Boolean.valueOf(view.getChildren().size()>0));
>> Map options = null;
>> options =
>> Collections.singletonMap(Transaction.OPTION_UNPROTECTED,
>> Boolean.TRUE);
>>
>> AbstractEMFOperation operation = new AbstractEMFOperation(
>> getEditingDomain(),
>> StringStatics.BLANK, options) {
>>
>> protected IStatus doExecute(IProgressMonitor monitor,
>> IAdaptable info)
>> throws ExecutionException {
>>
>> cmd.execute(null,null);
>>
>> return Status.OK_STATUS;
>> }
>> };
>> try {
>> operation.execute(new NullProgressMonitor(), null);
>> } catch (ExecutionException e) {
>> int i = 0 ;
>> i++;
>> }
>>
>> 2- you have to be careful about setting the view visibility to False,
>> because as soon as you set it to false the edit part till be removed
>> completely. This means you will not be able to use the tool to create
>> the children any more, and you have to provide a different way to do that
>>
>>
>>
>>
>> Matthias Köster wrote:
>>
>>
>>> Hi Michael,
>>>
>>> As a workaround i've overriden the
>>> ListCompartmentEditPart.refreshVisibility method:
>>>
>>> protected void refreshVisibility() {
>>> final View notationView = getNotationView();
>>> final boolean hasChildren = notationView .getChildren().size() > 0;
>>> setVisibility(hasChildren); }
>>>
>>> This just changes the visibility of the edit part and not of the
>>> view. But when i changed the view visibility i got some transaction
>>> related exceptions! Perhaps someone has a better solution?
>>>
>>> You also have to call this method if a children is added or removed,
>>> this can be done by overriding the notifyChanged method of your
>>> comparment edit part.
>>>
>>> Matthias
>>>
>>> Michael Haeberlen wrote:
>>>
>>>> Hello,
>>>>
>>>> I'm looking for a workaround for
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=147855
>>>> Does anyone has an idea how to make this working?
>>>>
>>>> Any hint is highly appreciated
>>>>
>>>> Michael
|
|
|
Goto Forum:
Current Time: Sun May 11 00:55:22 EDT 2025
Powered by FUDForum. Page generated in 0.03947 seconds
|