Home » Modeling » GMF (Graphical Modeling Framework) » How can remove orphan views without reopening the editor
| How can remove orphan views without reopening the editor [message #76223] |
Thu, 09 November 2006 09:15  |
Eclipse User |
|
|
|
Hi,
I have a custom view in which are displayed the model elements of all my
editors (these editors shared the same model resource by using the same
editing domain). From this view I can execute drag and drop of elements into
my editors. Moreover I can remove elements from the model resource through
an action on my custom view (by the use of the DestroyElementCommand). But I
don't know what I have to do in order to refresh the editors (which contain
orphan element views after the remove action executed in the custom view)
without reopening them.
I made some attempts on the editPart of the diagram container element, but
without success.
Any suggestion ?
Thanks in advance.
Best regards,
Fabio.
|
|
| |
| Re: How can remove orphan views without reopening the editor [message #76398 is a reply to message #76304] |
Fri, 10 November 2006 04:26  |
| Eclipse User |
|
|
|
Hi Mohammed,
thank you so much for your reply.
In the NotationViewDependentsAdvice class the only present method is the
getBeforeDestroyDependentsCommand (Did you refer to it ?).
If I put a break point in this method, this break point is hit only if I
delete an element by means of the canc button, but it doesn't hit if I
delete an element
from my custom view. The run method of the action in my custom view is the
following:
public void run() {
ISelection selection = viewer.getSelection();
Object obj = ((IStructuredSelection)selection).getFirstElement();
if(! (obj instanceof PModel) && (obj instanceof EObject) {
final EObject eObject = (EObject)obj;
Resource resource = eObject.eResource();
if (resource != null) {
DestroyElementRequest destroy = new
DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
ICommand command = new DestroyElementCommand(destroy);
try {
command.execute(new NullProgressMonitor(), null);
}
catch(ExecutionException e) {
e.printStackTrace();
}
try {
resource.save(Collections.EMPTY_MAP);
showMessage("Element has been removed!");
}
catch (IOException e) {
return ;
}
........
A strange thing happens after I delete an element from my custom view: the
name of the element view into the diagram becames the name of the container
element of the diagram (the root of my custom view).
Moreover, I added a IPartListener on my editor in order to update my custom
view to reflect the model elements of the project that own that editor (in
each project there is an unique model through the same editing domain). If
the activated editor is an editor of another project, I update my custom
view.
I hope to call an update operation of the diagram here, inside the
partActivated method.
But I don't know what operation is made when I close and thus reopen the
diagram. This operation is what I'm looking for.
Have I to make anything with the model resource ? or Have I to make a forced
refresh of the diagram ?
Thanks again.
Best regards,
Fabio.
"Mohammed Mostafa" <mmostafa@ca.ibm.com> ha scritto nel messaggio
news:eivm60$q4g$1@utils.eclipse.org...
> Hi Fabio;
>
> When you delete a semantic element all views, currently in memory,
> pointing to this semantic element are supposed to be deleted.
> This is done in the NotationViewDependentsAdvice class
> I suggest putting a break point in the getDestroyDependentsCommand method
> in this class.
>
> We need to know if you hit the break point or not ? and if you hit it did
> it destroy the views ?
>
> if you hit the break point and find that
> crossReferenceAdapter.getNonNavigableInverseReferences(destr uctee);
>
> returns empty or incomplete set then most probably the resources
> containing your views are not loaded yet. If this is the case the default
> implementation of the canonical edit policy will not help you (I can
> explain later if we confirm this is the case).
>
>
>
>
>
> Fabio Centineo wrote:
>> Hi,
>> I have a custom view in which are displayed the model elements of all my
>> editors (these editors shared the same model resource by using the same
>> editing domain). From this view I can execute drag and drop of elements
>> into my editors. Moreover I can remove elements from the model resource
>> through an action on my custom view (by the use of the
>> DestroyElementCommand). But I don't know what I have to do in order to
>> refresh the editors (which contain orphan element views after the remove
>> action executed in the custom view) without reopening them.
>> I made some attempts on the editPart of the diagram container element,
>> but without success.
>> Any suggestion ?
>>
>> Thanks in advance.
>>
>> Best regards,
>> Fabio.
>>
>>
|
|
|
| Re: How can remove orphan views without reopening the editor [message #76540 is a reply to message #76398] |
Fri, 10 November 2006 09:13 |
| Eclipse User |
|
|
|
Fabio,
Try
IElementType type =
ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
ICommand command = (type != null) ?
type.getEditCommand(completedRequest) : null;
OperationHistoryFactory.getOperationHistory().execute(comman d, new
NullProgressMonitor(), null);
from your action instead of creating a new destroy command manually.
When you instantiate the command yourself you won't get the advice (such
as NotationViewDependentsAdvice) that is contributed via the
elementTypes extension point.
Fabio Centineo wrote:
> Hi Mohammed,
> thank you so much for your reply.
> In the NotationViewDependentsAdvice class the only present method is the
> getBeforeDestroyDependentsCommand (Did you refer to it ?).
> If I put a break point in this method, this break point is hit only if I
> delete an element by means of the canc button, but it doesn't hit if I
> delete an element
> from my custom view. The run method of the action in my custom view is the
> following:
>
> public void run() {
> ISelection selection = viewer.getSelection();
> Object obj = ((IStructuredSelection)selection).getFirstElement();
> if(! (obj instanceof PModel) && (obj instanceof EObject) {
> final EObject eObject = (EObject)obj;
> Resource resource = eObject.eResource();
> if (resource != null) {
> DestroyElementRequest destroy = new
> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
> ICommand command = new DestroyElementCommand(destroy);
> try {
> command.execute(new NullProgressMonitor(), null);
> }
> catch(ExecutionException e) {
> e.printStackTrace();
> }
> try {
> resource.save(Collections.EMPTY_MAP);
> showMessage("Element has been removed!");
> }
> catch (IOException e) {
> return ;
> }
> .......
>
> A strange thing happens after I delete an element from my custom view: the
> name of the element view into the diagram becames the name of the container
> element of the diagram (the root of my custom view).
> Moreover, I added a IPartListener on my editor in order to update my custom
> view to reflect the model elements of the project that own that editor (in
> each project there is an unique model through the same editing domain). If
> the activated editor is an editor of another project, I update my custom
> view.
> I hope to call an update operation of the diagram here, inside the
> partActivated method.
> But I don't know what operation is made when I close and thus reopen the
> diagram. This operation is what I'm looking for.
> Have I to make anything with the model resource ? or Have I to make a forced
> refresh of the diagram ?
>
> Thanks again.
>
> Best regards,
> Fabio.
>
>
>
>
> "Mohammed Mostafa" <mmostafa@ca.ibm.com> ha scritto nel messaggio
> news:eivm60$q4g$1@utils.eclipse.org...
>> Hi Fabio;
>>
>> When you delete a semantic element all views, currently in memory,
>> pointing to this semantic element are supposed to be deleted.
>> This is done in the NotationViewDependentsAdvice class
>> I suggest putting a break point in the getDestroyDependentsCommand method
>> in this class.
>>
>> We need to know if you hit the break point or not ? and if you hit it did
>> it destroy the views ?
>>
>> if you hit the break point and find that
>> crossReferenceAdapter.getNonNavigableInverseReferences(destr uctee);
>>
>> returns empty or incomplete set then most probably the resources
>> containing your views are not loaded yet. If this is the case the default
>> implementation of the canonical edit policy will not help you (I can
>> explain later if we confirm this is the case).
>>
>>
>>
>>
>>
>> Fabio Centineo wrote:
>>> Hi,
>>> I have a custom view in which are displayed the model elements of all my
>>> editors (these editors shared the same model resource by using the same
>>> editing domain). From this view I can execute drag and drop of elements
>>> into my editors. Moreover I can remove elements from the model resource
>>> through an action on my custom view (by the use of the
>>> DestroyElementCommand). But I don't know what I have to do in order to
>>> refresh the editors (which contain orphan element views after the remove
>>> action executed in the custom view) without reopening them.
>>> I made some attempts on the editPart of the diagram container element,
>>> but without success.
>>> Any suggestion ?
>>>
>>> Thanks in advance.
>>>
>>> Best regards,
>>> Fabio.
>>>
>>>
>
|
|
|
| Re: How can remove orphan views without reopening the editor [message #76731 is a reply to message #76540] |
Fri, 10 November 2006 11:09 |
| Eclipse User |
|
|
|
Hi Linda,
thank you so much for your reply.
The source code I implemented is the following:
DestroyElementRequest destroy = new
DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
IElementType type =
ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
ICommand command = (type != null) ? type.getEditCommand(destroy) : null;
try {
OperationHistoryFactory.getOperationHistory().execute(comman d, new
NullProgressMonitor(), null);
}
catch(ExecutionException e)
{
e.printStackTrace();
}
Is this right ?
I followed the whole process through debug, but a problem occurs: the
ICompositeCommand builded inside the method
getEditCommand() of the AbstractEditHelper class is empty. All the followed
commands are null:
ICommand beforeAdvice = nextAdvice.getBeforeEditCommand(req);
ICommand insteadCommand = getInsteadCommand(req);
ICommand afterAdvice = nextAdvice.getAfterEditCommand(req);
As a result, the command inside the
OperationHistoryFactory.getOperationHistory().execute(comman d, new
NullProgressMonitor(), null) method is
a null command.
This doesn't happen if I delete an element by means of the canc button for
which the ICommand insteadCommand = getInsteadCommand(req);
is a not null command.
What should I do? Did I forget to do anything?
Thanks again for your help.
Best regards,
Fabio.
"Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
news:ej21ds$p7v$1@utils.eclipse.org...
> Fabio,
>
> Try
> IElementType type =
> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
> ICommand command = (type != null) ? type.getEditCommand(completedRequest)
> : null;
> OperationHistoryFactory.getOperationHistory().execute(comman d, new
> NullProgressMonitor(), null);
>
> from your action instead of creating a new destroy command manually.
>
> When you instantiate the command yourself you won't get the advice (such
> as NotationViewDependentsAdvice) that is contributed via the elementTypes
> extension point.
>
> Fabio Centineo wrote:
>> Hi Mohammed,
>> thank you so much for your reply.
>> In the NotationViewDependentsAdvice class the only present method is the
>> getBeforeDestroyDependentsCommand (Did you refer to it ?).
>> If I put a break point in this method, this break point is hit only if I
>> delete an element by means of the canc button, but it doesn't hit if I
>> delete an element
>> from my custom view. The run method of the action in my custom view is
>> the following:
>>
>> public void run() {
>> ISelection selection = viewer.getSelection();
>> Object obj = ((IStructuredSelection)selection).getFirstElement();
>> if(! (obj instanceof PModel) && (obj instanceof EObject) {
>> final EObject eObject = (EObject)obj;
>> Resource resource = eObject.eResource();
>> if (resource != null) {
>> DestroyElementRequest destroy = new
>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>> ICommand command = new DestroyElementCommand(destroy);
>> try {
>> command.execute(new NullProgressMonitor(), null);
>> }
>> catch(ExecutionException e) {
>> e.printStackTrace();
>> }
>> try {
>> resource.save(Collections.EMPTY_MAP);
>> showMessage("Element has been removed!");
>> }
>> catch (IOException e) {
>> return ;
>> }
>> .......
>>
>> A strange thing happens after I delete an element from my custom view:
>> the name of the element view into the diagram becames the name of the
>> container element of the diagram (the root of my custom view).
>> Moreover, I added a IPartListener on my editor in order to update my
>> custom view to reflect the model elements of the project that own that
>> editor (in each project there is an unique model through the same editing
>> domain). If the activated editor is an editor of another project, I
>> update my custom view.
>> I hope to call an update operation of the diagram here, inside the
>> partActivated method.
>> But I don't know what operation is made when I close and thus reopen the
>> diagram. This operation is what I'm looking for.
>> Have I to make anything with the model resource ? or Have I to make a
>> forced refresh of the diagram ?
>>
>> Thanks again.
>>
>> Best regards,
>> Fabio.
>>
>>
>>
>>
>> "Mohammed Mostafa" <mmostafa@ca.ibm.com> ha scritto nel messaggio
>> news:eivm60$q4g$1@utils.eclipse.org...
>>> Hi Fabio;
>>>
>>> When you delete a semantic element all views, currently in memory,
>>> pointing to this semantic element are supposed to be deleted.
>>> This is done in the NotationViewDependentsAdvice class
>>> I suggest putting a break point in the getDestroyDependentsCommand
>>> method in this class.
>>>
>>> We need to know if you hit the break point or not ? and if you hit it
>>> did it destroy the views ?
>>>
>>> if you hit the break point and find that
>>> crossReferenceAdapter.getNonNavigableInverseReferences(destr uctee);
>>>
>>> returns empty or incomplete set then most probably the resources
>>> containing your views are not loaded yet. If this is the case the
>>> default implementation of the canonical edit policy will not help you (I
>>> can explain later if we confirm this is the case).
>>>
>>>
>>>
>>>
>>>
>>> Fabio Centineo wrote:
>>>> Hi,
>>>> I have a custom view in which are displayed the model elements of all
>>>> my editors (these editors shared the same model resource by using the
>>>> same editing domain). From this view I can execute drag and drop of
>>>> elements into my editors. Moreover I can remove elements from the model
>>>> resource through an action on my custom view (by the use of the
>>>> DestroyElementCommand). But I don't know what I have to do in order to
>>>> refresh the editors (which contain orphan element views after the
>>>> remove action executed in the custom view) without reopening them.
>>>> I made some attempts on the editPart of the diagram container element,
>>>> but without success.
>>>> Any suggestion ?
>>>>
>>>> Thanks in advance.
>>>>
>>>> Best regards,
>>>> Fabio.
>>>>
>>>>
>>
|
|
|
| Re: How can remove orphan views without reopening the editor [message #76793 is a reply to message #76731] |
Fri, 10 November 2006 12:23 |
| Eclipse User |
|
|
|
Fabio,
Your code looks correct to me (just remember to check that the command
isn't null and is executable before executing on the operation history -
I should have put that in my original snippet :-)).
When you compare the delete case that works (using the keyboard on the
diagram?) with the one that doesn't (from your custom view), is it the
same kind of eObject in the same kind of container that is being deleted?
Fabio Centineo wrote:
> Hi Linda,
> thank you so much for your reply.
> The source code I implemented is the following:
>
> DestroyElementRequest destroy = new
> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
> IElementType type =
> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
> ICommand command = (type != null) ? type.getEditCommand(destroy) : null;
> try {
> OperationHistoryFactory.getOperationHistory().execute(comman d, new
> NullProgressMonitor(), null);
> }
> catch(ExecutionException e)
> {
> e.printStackTrace();
> }
>
> Is this right ?
> I followed the whole process through debug, but a problem occurs: the
> ICompositeCommand builded inside the method
> getEditCommand() of the AbstractEditHelper class is empty. All the followed
> commands are null:
>
> ICommand beforeAdvice = nextAdvice.getBeforeEditCommand(req);
> ICommand insteadCommand = getInsteadCommand(req);
> ICommand afterAdvice = nextAdvice.getAfterEditCommand(req);
>
> As a result, the command inside the
> OperationHistoryFactory.getOperationHistory().execute(comman d, new
> NullProgressMonitor(), null) method is
> a null command.
> This doesn't happen if I delete an element by means of the canc button for
> which the ICommand insteadCommand = getInsteadCommand(req);
> is a not null command.
> What should I do? Did I forget to do anything?
>
> Thanks again for your help.
>
> Best regards,
> Fabio.
>
>
> "Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
> news:ej21ds$p7v$1@utils.eclipse.org...
>> Fabio,
>>
>> Try
>> IElementType type =
>> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
>> ICommand command = (type != null) ? type.getEditCommand(completedRequest)
>> : null;
>> OperationHistoryFactory.getOperationHistory().execute(comman d, new
>> NullProgressMonitor(), null);
>>
>> from your action instead of creating a new destroy command manually.
>>
>> When you instantiate the command yourself you won't get the advice (such
>> as NotationViewDependentsAdvice) that is contributed via the elementTypes
>> extension point.
>>
>> Fabio Centineo wrote:
>>> Hi Mohammed,
>>> thank you so much for your reply.
>>> In the NotationViewDependentsAdvice class the only present method is the
>>> getBeforeDestroyDependentsCommand (Did you refer to it ?).
>>> If I put a break point in this method, this break point is hit only if I
>>> delete an element by means of the canc button, but it doesn't hit if I
>>> delete an element
>>> from my custom view. The run method of the action in my custom view is
>>> the following:
>>>
>>> public void run() {
>>> ISelection selection = viewer.getSelection();
>>> Object obj = ((IStructuredSelection)selection).getFirstElement();
>>> if(! (obj instanceof PModel) && (obj instanceof EObject) {
>>> final EObject eObject = (EObject)obj;
>>> Resource resource = eObject.eResource();
>>> if (resource != null) {
>>> DestroyElementRequest destroy = new
>>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>>> ICommand command = new DestroyElementCommand(destroy);
>>> try {
>>> command.execute(new NullProgressMonitor(), null);
>>> }
>>> catch(ExecutionException e) {
>>> e.printStackTrace();
>>> }
>>> try {
>>> resource.save(Collections.EMPTY_MAP);
>>> showMessage("Element has been removed!");
>>> }
>>> catch (IOException e) {
>>> return ;
>>> }
>>> .......
>>>
>>> A strange thing happens after I delete an element from my custom view:
>>> the name of the element view into the diagram becames the name of the
>>> container element of the diagram (the root of my custom view).
>>> Moreover, I added a IPartListener on my editor in order to update my
>>> custom view to reflect the model elements of the project that own that
>>> editor (in each project there is an unique model through the same editing
>>> domain). If the activated editor is an editor of another project, I
>>> update my custom view.
>>> I hope to call an update operation of the diagram here, inside the
>>> partActivated method.
>>> But I don't know what operation is made when I close and thus reopen the
>>> diagram. This operation is what I'm looking for.
>>> Have I to make anything with the model resource ? or Have I to make a
>>> forced refresh of the diagram ?
>>>
>>> Thanks again.
>>>
>>> Best regards,
>>> Fabio.
>>>
>>>
>>>
>>>
>>> "Mohammed Mostafa" <mmostafa@ca.ibm.com> ha scritto nel messaggio
>>> news:eivm60$q4g$1@utils.eclipse.org...
>>>> Hi Fabio;
>>>>
>>>> When you delete a semantic element all views, currently in memory,
>>>> pointing to this semantic element are supposed to be deleted.
>>>> This is done in the NotationViewDependentsAdvice class
>>>> I suggest putting a break point in the getDestroyDependentsCommand
>>>> method in this class.
>>>>
>>>> We need to know if you hit the break point or not ? and if you hit it
>>>> did it destroy the views ?
>>>>
>>>> if you hit the break point and find that
>>>> crossReferenceAdapter.getNonNavigableInverseReferences(destr uctee);
>>>>
>>>> returns empty or incomplete set then most probably the resources
>>>> containing your views are not loaded yet. If this is the case the
>>>> default implementation of the canonical edit policy will not help you (I
>>>> can explain later if we confirm this is the case).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Fabio Centineo wrote:
>>>>> Hi,
>>>>> I have a custom view in which are displayed the model elements of all
>>>>> my editors (these editors shared the same model resource by using the
>>>>> same editing domain). From this view I can execute drag and drop of
>>>>> elements into my editors. Moreover I can remove elements from the model
>>>>> resource through an action on my custom view (by the use of the
>>>>> DestroyElementCommand). But I don't know what I have to do in order to
>>>>> refresh the editors (which contain orphan element views after the
>>>>> remove action executed in the custom view) without reopening them.
>>>>> I made some attempts on the editPart of the diagram container element,
>>>>> but without success.
>>>>> Any suggestion ?
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> Best regards,
>>>>> Fabio.
>>>>>
>>>>>
>
>
|
|
|
| Re: How can remove orphan views without reopening the editor [message #77343 is a reply to message #76793] |
Tue, 14 November 2006 05:21 |
| Eclipse User |
|
|
|
Hi Linda,
sorry for my late reply, I had a lot to do ;-((.
The command is null, e thus I can't execute it.
A very strange case happens: if I have a diagram with an element view, If I
delete this element view from my custom view, the element of the view
becomes the container element of the diagram, in fact the displayed name of
the element view in the diagram is that of the container element of the
diagram.
It seems that somewhere the element of the view is setted with the container
element of the diagram.
The above situation is the main problem for which the refresh methods of the
diagram don't work: the view into the diagram is an orphan one, but as its
element is the element container, is it impossible to delete it. Only if the
diagram is closed and reopened is it possible execute a refresh operation.
In order to solve this problem, in my custom view I use my first
DestroyElementCommand and in the CanonicalEditPolicy of the delement
container, I modified the method shouldDeleteView:
protected boolean shouldDeleteView(View view)
{
if(view.getElement() instanceof PModel) //Note: PModel is the container
element of the diagram.
return true;
return view.isSetElement() && view.getElement() != null &&
view.getElement().eIsProxy();
}
Now, so I have a IPartListener installed on my editor, when the editor is
activated, I call the refresh method of its CanonicalEditPolicy, and the
diagram is refreshed :-)).
What do you think about ? Have I to procede in a different a more correct
way ?
Thanks again.
Best regards,
Fabio.
"Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
news:ej2cih$lat$1@utils.eclipse.org...
> Fabio,
>
> Your code looks correct to me (just remember to check that the command
> isn't null and is executable before executing on the operation history - I
> should have put that in my original snippet :-)).
>
> When you compare the delete case that works (using the keyboard on the
> diagram?) with the one that doesn't (from your custom view), is it the
> same kind of eObject in the same kind of container that is being deleted?
>
> Fabio Centineo wrote:
>> Hi Linda,
>> thank you so much for your reply.
>> The source code I implemented is the following:
>>
>> DestroyElementRequest destroy = new
>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>> IElementType type =
>> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
>> ICommand command = (type != null) ? type.getEditCommand(destroy) : null;
>> try {
>> OperationHistoryFactory.getOperationHistory().execute(comman d,
>> new NullProgressMonitor(), null);
>> }
>> catch(ExecutionException e)
>> {
>> e.printStackTrace();
>> }
>>
>> Is this right ?
>> I followed the whole process through debug, but a problem occurs: the
>> ICompositeCommand builded inside the method
>> getEditCommand() of the AbstractEditHelper class is empty. All the
>> followed commands are null:
>>
>> ICommand beforeAdvice = nextAdvice.getBeforeEditCommand(req);
>> ICommand insteadCommand = getInsteadCommand(req);
>> ICommand afterAdvice = nextAdvice.getAfterEditCommand(req);
>>
>> As a result, the command inside the
>> OperationHistoryFactory.getOperationHistory().execute(comman d, new
>> NullProgressMonitor(), null) method is
>> a null command.
>> This doesn't happen if I delete an element by means of the canc button
>> for which the ICommand insteadCommand = getInsteadCommand(req);
>> is a not null command.
>> What should I do? Did I forget to do anything?
>>
>> Thanks again for your help.
>>
>> Best regards,
>> Fabio.
>>
>>
>> "Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
>> news:ej21ds$p7v$1@utils.eclipse.org...
>>> Fabio,
>>>
>>> Try
>>> IElementType type =
>>> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
>>> ICommand command = (type != null) ?
>>> type.getEditCommand(completedRequest) : null;
>>> OperationHistoryFactory.getOperationHistory().execute(comman d, new
>>> NullProgressMonitor(), null);
>>>
>>> from your action instead of creating a new destroy command manually.
>>>
>>> When you instantiate the command yourself you won't get the advice (such
>>> as NotationViewDependentsAdvice) that is contributed via the
>>> elementTypes extension point.
>>>
>>> Fabio Centineo wrote:
>>>> Hi Mohammed,
>>>> thank you so much for your reply.
>>>> In the NotationViewDependentsAdvice class the only present method is
>>>> the getBeforeDestroyDependentsCommand (Did you refer to it ?).
>>>> If I put a break point in this method, this break point is hit only if
>>>> I delete an element by means of the canc button, but it doesn't hit if
>>>> I delete an element
>>>> from my custom view. The run method of the action in my custom view is
>>>> the following:
>>>>
>>>> public void run() {
>>>> ISelection selection = viewer.getSelection();
>>>> Object obj = ((IStructuredSelection)selection).getFirstElement();
>>>> if(! (obj instanceof PModel) && (obj instanceof EObject) {
>>>> final EObject eObject = (EObject)obj;
>>>> Resource resource = eObject.eResource();
>>>> if (resource != null) {
>>>> DestroyElementRequest destroy = new
>>>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>>>> ICommand command = new DestroyElementCommand(destroy);
>>>> try {
>>>> command.execute(new NullProgressMonitor(), null);
>>>> }
>>>> catch(ExecutionException e) {
>>>> e.printStackTrace();
>>>> }
>>>> try {
>>>> resource.save(Collections.EMPTY_MAP);
>>>> showMessage("Element has been removed!");
>>>> }
>>>> catch (IOException e) {
>>>> return ;
>>>> }
>>>> .......
>>>>
>>>> A strange thing happens after I delete an element from my custom view:
>>>> the name of the element view into the diagram becames the name of the
>>>> container element of the diagram (the root of my custom view).
>>>> Moreover, I added a IPartListener on my editor in order to update my
>>>> custom view to reflect the model elements of the project that own that
>>>> editor (in each project there is an unique model through the same
>>>> editing domain). If the activated editor is an editor of another
>>>> project, I update my custom view.
>>>> I hope to call an update operation of the diagram here, inside the
>>>> partActivated method.
>>>> But I don't know what operation is made when I close and thus reopen
>>>> the diagram. This operation is what I'm looking for.
>>>> Have I to make anything with the model resource ? or Have I to make a
>>>> forced refresh of the diagram ?
>>>>
>>>> Thanks again.
>>>>
>>>> Best regards,
>>>> Fabio.
>>>>
>>>>
>>>>
>>>>
>>>> "Mohammed Mostafa" <mmostafa@ca.ibm.com> ha scritto nel messaggio
>>>> news:eivm60$q4g$1@utils.eclipse.org...
>>>>> Hi Fabio;
>>>>>
>>>>> When you delete a semantic element all views, currently in memory,
>>>>> pointing to this semantic element are supposed to be deleted.
>>>>> This is done in the NotationViewDependentsAdvice class
>>>>> I suggest putting a break point in the getDestroyDependentsCommand
>>>>> method in this class.
>>>>>
>>>>> We need to know if you hit the break point or not ? and if you hit it
>>>>> did it destroy the views ?
>>>>>
>>>>> if you hit the break point and find that
>>>>> crossReferenceAdapter.getNonNavigableInverseReferences(destr uctee);
>>>>>
>>>>> returns empty or incomplete set then most probably the resources
>>>>> containing your views are not loaded yet. If this is the case the
>>>>> default implementation of the canonical edit policy will not help you
>>>>> (I can explain later if we confirm this is the case).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Fabio Centineo wrote:
>>>>>> Hi,
>>>>>> I have a custom view in which are displayed the model elements of all
>>>>>> my editors (these editors shared the same model resource by using the
>>>>>> same editing domain). From this view I can execute drag and drop of
>>>>>> elements into my editors. Moreover I can remove elements from the
>>>>>> model resource through an action on my custom view (by the use of the
>>>>>> DestroyElementCommand). But I don't know what I have to do in order
>>>>>> to refresh the editors (which contain orphan element views after the
>>>>>> remove action executed in the custom view) without reopening them.
>>>>>> I made some attempts on the editPart of the diagram container
>>>>>> element, but without success.
>>>>>> Any suggestion ?
>>>>>>
>>>>>> Thanks in advance.
>>>>>>
>>>>>> Best regards,
>>>>>> Fabio.
>>>>>>
>>>>>>
>>
|
|
|
| Re: How can remove orphan views without reopening the editor [message #77455 is a reply to message #77343] |
Tue, 14 November 2006 10:07 |
| Eclipse User |
|
|
|
Fabio,
Linda and I were discussing your issue. You shouldn't need to do what
you are doing to refresh the diagram. Here are some things to consider...
1. As Linda suggested, I think you should compare how the delete command
differs when the delete is triggered from the diagram and when it is
triggered from your custom view. Try putting a breakpoint in the
SemanticEditPolicy generated for the element that will get deleted to
see how the delete command is constructed.
1. If you are deleting the element from your custom view, and the view
of the element on the diagram is being updated with the name of the
container element, then your diagram IS responding to the deletion of
the element (just not in the way that you want). I would suggest
putting a breakpoint in these locations to try to figure out what is
going on:
- in the handleNotificationEvent() method of the editpart class
representing the element on the diagram and the editpart class of its
name label editpart
- in the notifyChanged() method of your canonical editpolicy.
3. When you open a diagram editor, if it has a CanonicalEditPolicy
installed, its activate() method will be called which should refresh the
diagram. In other words, you shouldn't need to add any special
listeners in this case.
I hope this helps.
- Cherie
Fabio Centineo wrote:
> Hi Linda,
> sorry for my late reply, I had a lot to do ;-((.
> The command is null, e thus I can't execute it.
>
> A very strange case happens: if I have a diagram with an element view, If I
> delete this element view from my custom view, the element of the view
> becomes the container element of the diagram, in fact the displayed name of
> the element view in the diagram is that of the container element of the
> diagram.
> It seems that somewhere the element of the view is setted with the container
> element of the diagram.
> The above situation is the main problem for which the refresh methods of the
> diagram don't work: the view into the diagram is an orphan one, but as its
> element is the element container, is it impossible to delete it. Only if the
> diagram is closed and reopened is it possible execute a refresh operation.
> In order to solve this problem, in my custom view I use my first
> DestroyElementCommand and in the CanonicalEditPolicy of the delement
> container, I modified the method shouldDeleteView:
>
> protected boolean shouldDeleteView(View view)
> {
> if(view.getElement() instanceof PModel) //Note: PModel is the container
> element of the diagram.
> return true;
>
> return view.isSetElement() && view.getElement() != null &&
> view.getElement().eIsProxy();
> }
>
> Now, so I have a IPartListener installed on my editor, when the editor is
> activated, I call the refresh method of its CanonicalEditPolicy, and the
> diagram is refreshed :-)).
>
> What do you think about ? Have I to procede in a different a more correct
> way ?
>
> Thanks again.
>
> Best regards,
> Fabio.
>
>
>
> "Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
> news:ej2cih$lat$1@utils.eclipse.org...
>> Fabio,
>>
>> Your code looks correct to me (just remember to check that the command
>> isn't null and is executable before executing on the operation history - I
>> should have put that in my original snippet :-)).
>>
>> When you compare the delete case that works (using the keyboard on the
>> diagram?) with the one that doesn't (from your custom view), is it the
>> same kind of eObject in the same kind of container that is being deleted?
>>
>> Fabio Centineo wrote:
>>> Hi Linda,
>>> thank you so much for your reply.
>>> The source code I implemented is the following:
>>>
>>> DestroyElementRequest destroy = new
>>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>>> IElementType type =
>>> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
>>> ICommand command = (type != null) ? type.getEditCommand(destroy) : null;
>>> try {
>>> OperationHistoryFactory.getOperationHistory().execute(comman d,
>>> new NullProgressMonitor(), null);
>>> }
>>> catch(ExecutionException e)
>>> {
>>> e.printStackTrace();
>>> }
>>>
>>> Is this right ?
>>> I followed the whole process through debug, but a problem occurs: the
>>> ICompositeCommand builded inside the method
>>> getEditCommand() of the AbstractEditHelper class is empty. All the
>>> followed commands are null:
>>>
>>> ICommand beforeAdvice = nextAdvice.getBeforeEditCommand(req);
>>> ICommand insteadCommand = getInsteadCommand(req);
>>> ICommand afterAdvice = nextAdvice.getAfterEditCommand(req);
>>>
>>> As a result, the command inside the
>>> OperationHistoryFactory.getOperationHistory().execute(comman d, new
>>> NullProgressMonitor(), null) method is
>>> a null command.
>>> This doesn't happen if I delete an element by means of the canc button
>>> for which the ICommand insteadCommand = getInsteadCommand(req);
>>> is a not null command.
>>> What should I do? Did I forget to do anything?
>>>
>>> Thanks again for your help.
>>>
>>> Best regards,
>>> Fabio.
>>>
>>>
>>> "Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
>>> news:ej21ds$p7v$1@utils.eclipse.org...
>>>> Fabio,
>>>>
>>>> Try
>>>> IElementType type =
>>>> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
>>>> ICommand command = (type != null) ?
>>>> type.getEditCommand(completedRequest) : null;
>>>> OperationHistoryFactory.getOperationHistory().execute(comman d, new
>>>> NullProgressMonitor(), null);
>>>>
>>>> from your action instead of creating a new destroy command manually.
>>>>
>>>> When you instantiate the command yourself you won't get the advice (such
>>>> as NotationViewDependentsAdvice) that is contributed via the
>>>> elementTypes extension point.
>>>>
>>>> Fabio Centineo wrote:
>>>>> Hi Mohammed,
>>>>> thank you so much for your reply.
>>>>> In the NotationViewDependentsAdvice class the only present method is
>>>>> the getBeforeDestroyDependentsCommand (Did you refer to it ?).
>>>>> If I put a break point in this method, this break point is hit only if
>>>>> I delete an element by means of the canc button, but it doesn't hit if
>>>>> I delete an element
>>>>> from my custom view. The run method of the action in my custom view is
>>>>> the following:
>>>>>
>>>>> public void run() {
>>>>> ISelection selection = viewer.getSelection();
>>>>> Object obj = ((IStructuredSelection)selection).getFirstElement();
>>>>> if(! (obj instanceof PModel) && (obj instanceof EObject) {
>>>>> final EObject eObject = (EObject)obj;
>>>>> Resource resource = eObject.eResource();
>>>>> if (resource != null) {
>>>>> DestroyElementRequest destroy = new
>>>>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>>>>> ICommand command = new DestroyElementCommand(destroy);
>>>>> try {
>>>>> command.execute(new NullProgressMonitor(), null);
>>>>> }
>>>>> catch(ExecutionException e) {
>>>>> e.printStackTrace();
>>>>> }
>>>>> try {
>>>>> resource.save(Collections.EMPTY_MAP);
>>>>> showMessage("Element has been removed!");
>>>>> }
>>>>> catch (IOException e) {
>>>>> return ;
>>>>> }
>>>>> .......
>>>>>
>>>>> A strange thing happens after I delete an element from my custom view:
>>>>> the name of the element view into the diagram becames the name of the
>>>>> container element of the diagram (the root of my custom view).
>>>>> Moreover, I added a IPartListener on my editor in order to update my
>>>>> custom view to reflect the model elements of the project that own that
>>>>> editor (in each project there is an unique model through the same
>>>>> editing domain). If the activated editor is an editor of another
>>>>> project, I update my custom view.
>>>>> I hope to call an update operation of the diagram here, inside the
>>>>> partActivated method.
>>>>> But I don't know what operation is made when I close and thus reopen
>>>>> the diagram. This operation is what I'm looking for.
>>>>> Have I to make anything with the model resource ? or Have I to make a
>>>>> forced refresh of the diagram ?
>>>>>
>>>>> Thanks again.
>>>>>
>>>>> Best regards,
>>>>> Fabio.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> "Mohammed Mostafa" <mmostafa@ca.ibm.com> ha scritto nel messaggio
>>>>> news:eivm60$q4g$1@utils.eclipse.org...
>>>>>> Hi Fabio;
>>>>>>
>>>>>> When you delete a semantic element all views, currently in memory,
>>>>>> pointing to this semantic element are supposed to be deleted.
>>>>>> This is done in the NotationViewDependentsAdvice class
>>>>>> I suggest putting a break point in the getDestroyDependentsCommand
>>>>>> method in this class.
>>>>>>
>>>>>> We need to know if you hit the break point or not ? and if you hit it
>>>>>> did it destroy the views ?
>>>>>>
>>>>>> if you hit the break point and find that
>>>>>> crossReferenceAdapter.getNonNavigableInverseReferences(destr uctee);
>>>>>>
>>>>>> returns empty or incomplete set then most probably the resources
>>>>>> containing your views are not loaded yet. If this is the case the
>>>>>> default implementation of the canonical edit policy will not help you
>>>>>> (I can explain later if we confirm this is the case).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Fabio Centineo wrote:
>>>>>>> Hi,
>>>>>>> I have a custom view in which are displayed the model elements of all
>>>>>>> my editors (these editors shared the same model resource by using the
>>>>>>> same editing domain). From this view I can execute drag and drop of
>>>>>>> elements into my editors. Moreover I can remove elements from the
>>>>>>> model resource through an action on my custom view (by the use of the
>>>>>>> DestroyElementCommand). But I don't know what I have to do in order
>>>>>>> to refresh the editors (which contain orphan element views after the
>>>>>>> remove action executed in the custom view) without reopening them.
>>>>>>> I made some attempts on the editPart of the diagram container
>>>>>>> element, but without success.
>>>>>>> Any suggestion ?
>>>>>>>
>>>>>>> Thanks in advance.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Fabio.
>>>>>>>
>>>>>>>
>
|
|
|
| Re: How can remove orphan views without reopening the editor [message #77467 is a reply to message #77343] |
Tue, 14 November 2006 10:22 |
| Eclipse User |
|
|
|
Hi Fabio;
The way get element works is, when get element is called on any view,
the view will check if the element feature is set or not; if it is not
set it will just forward the call to the container of the view.
This might be the case here, you can put a break point in
ViewImpl#getElement to see if it is returning different element just
because the element is unset or not.
regarding deleting views in canonical edit policies, some people try to
avoid this as much as they can since it had one side effect, which is
soon as you open your diagram the model will be dirty which might not be
expected by users of your diagram.
I would think that the best way to handle this case will be using
ElementType or a TriggerListener. If you are ok with the fact that you
diagram will be dirtied during opening the editor then the canonical
edit policy approach might be acceptable but keep in mind the view will
stay in your model till some one open the diagram.
Fabio Centineo wrote:
> Hi Linda,
> sorry for my late reply, I had a lot to do ;-((.
> The command is null, e thus I can't execute it.
>
> A very strange case happens: if I have a diagram with an element view, If I
> delete this element view from my custom view, the element of the view
> becomes the container element of the diagram, in fact the displayed name of
> the element view in the diagram is that of the container element of the
> diagram.
> It seems that somewhere the element of the view is setted with the container
> element of the diagram.
> The above situation is the main problem for which the refresh methods of the
> diagram don't work: the view into the diagram is an orphan one, but as its
> element is the element container, is it impossible to delete it. Only if the
> diagram is closed and reopened is it possible execute a refresh operation.
> In order to solve this problem, in my custom view I use my first
> DestroyElementCommand and in the CanonicalEditPolicy of the delement
> container, I modified the method shouldDeleteView:
>
> protected boolean shouldDeleteView(View view)
> {
> if(view.getElement() instanceof PModel) //Note: PModel is the container
> element of the diagram.
> return true;
>
> return view.isSetElement() && view.getElement() != null &&
> view.getElement().eIsProxy();
> }
>
> Now, so I have a IPartListener installed on my editor, when the editor is
> activated, I call the refresh method of its CanonicalEditPolicy, and the
> diagram is refreshed :-)).
>
> What do you think about ? Have I to procede in a different a more correct
> way ?
>
> Thanks again.
>
> Best regards,
> Fabio.
>
>
>
> "Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
> news:ej2cih$lat$1@utils.eclipse.org...
>> Fabio,
>>
>> Your code looks correct to me (just remember to check that the command
>> isn't null and is executable before executing on the operation history - I
>> should have put that in my original snippet :-)).
>>
>> When you compare the delete case that works (using the keyboard on the
>> diagram?) with the one that doesn't (from your custom view), is it the
>> same kind of eObject in the same kind of container that is being deleted?
>>
>> Fabio Centineo wrote:
>>> Hi Linda,
>>> thank you so much for your reply.
>>> The source code I implemented is the following:
>>>
>>> DestroyElementRequest destroy = new
>>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>>> IElementType type =
>>> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
>>> ICommand command = (type != null) ? type.getEditCommand(destroy) : null;
>>> try {
>>> OperationHistoryFactory.getOperationHistory().execute(comman d,
>>> new NullProgressMonitor(), null);
>>> }
>>> catch(ExecutionException e)
>>> {
>>> e.printStackTrace();
>>> }
>>>
>>> Is this right ?
>>> I followed the whole process through debug, but a problem occurs: the
>>> ICompositeCommand builded inside the method
>>> getEditCommand() of the AbstractEditHelper class is empty. All the
>>> followed commands are null:
>>>
>>> ICommand beforeAdvice = nextAdvice.getBeforeEditCommand(req);
>>> ICommand insteadCommand = getInsteadCommand(req);
>>> ICommand afterAdvice = nextAdvice.getAfterEditCommand(req);
>>>
>>> As a result, the command inside the
>>> OperationHistoryFactory.getOperationHistory().execute(comman d, new
>>> NullProgressMonitor(), null) method is
>>> a null command.
>>> This doesn't happen if I delete an element by means of the canc button
>>> for which the ICommand insteadCommand = getInsteadCommand(req);
>>> is a not null command.
>>> What should I do? Did I forget to do anything?
>>>
>>> Thanks again for your help.
>>>
>>> Best regards,
>>> Fabio.
>>>
>>>
>>> "Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
>>> news:ej21ds$p7v$1@utils.eclipse.org...
>>>> Fabio,
>>>>
>>>> Try
>>>> IElementType type =
>>>> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
>>>> ICommand command = (type != null) ?
>>>> type.getEditCommand(completedRequest) : null;
>>>> OperationHistoryFactory.getOperationHistory().execute(comman d, new
>>>> NullProgressMonitor(), null);
>>>>
>>>> from your action instead of creating a new destroy command manually.
>>>>
>>>> When you instantiate the command yourself you won't get the advice (such
>>>> as NotationViewDependentsAdvice) that is contributed via the
>>>> elementTypes extension point.
>>>>
>>>> Fabio Centineo wrote:
>>>>> Hi Mohammed,
>>>>> thank you so much for your reply.
>>>>> In the NotationViewDependentsAdvice class the only present method is
>>>>> the getBeforeDestroyDependentsCommand (Did you refer to it ?).
>>>>> If I put a break point in this method, this break point is hit only if
>>>>> I delete an element by means of the canc button, but it doesn't hit if
>>>>> I delete an element
>>>>> from my custom view. The run method of the action in my custom view is
>>>>> the following:
>>>>>
>>>>> public void run() {
>>>>> ISelection selection = viewer.getSelection();
>>>>> Object obj = ((IStructuredSelection)selection).getFirstElement();
>>>>> if(! (obj instanceof PModel) && (obj instanceof EObject) {
>>>>> final EObject eObject = (EObject)obj;
>>>>> Resource resource = eObject.eResource();
>>>>> if (resource != null) {
>>>>> DestroyElementRequest destroy = new
>>>>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>>>>> ICommand command = new DestroyElementCommand(destroy);
>>>>> try {
>>>>> command.execute(new NullProgressMonitor(), null);
>>>>> }
>>>>> catch(ExecutionException e) {
>>>>> e.printStackTrace();
>>>>> }
>>>>> try {
>>>>> resource.save(Collections.EMPTY_MAP);
>>>>> showMessage("Element has been removed!");
>>>>> }
>>>>> catch (IOException e) {
>>>>> return ;
>>>>> }
>>>>> .......
>>>>>
>>>>> A strange thing happens after I delete an element from my custom view:
>>>>> the name of the element view into the diagram becames the name of the
>>>>> container element of the diagram (the root of my custom view).
>>>>> Moreover, I added a IPartListener on my editor in order to update my
>>>>> custom view to reflect the model elements of the project that own that
>>>>> editor (in each project there is an unique model through the same
>>>>> editing domain). If the activated editor is an editor of another
>>>>> project, I update my custom view.
>>>>> I hope to call an update operation of the diagram here, inside the
>>>>> partActivated method.
>>>>> But I don't know what operation is made when I close and thus reopen
>>>>> the diagram. This operation is what I'm looking for.
>>>>> Have I to make anything with the model resource ? or Have I to make a
>>>>> forced refresh of the diagram ?
>>>>>
>>>>> Thanks again.
>>>>>
>>>>> Best regards,
>>>>> Fabio.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> "Mohammed Mostafa" <mmostafa@ca.ibm.com> ha scritto nel messaggio
>>>>> news:eivm60$q4g$1@utils.eclipse.org...
>>>>>> Hi Fabio;
>>>>>>
>>>>>> When you delete a semantic element all views, currently in memory,
>>>>>> pointing to this semantic element are supposed to be deleted.
>>>>>> This is done in the NotationViewDependentsAdvice class
>>>>>> I suggest putting a break point in the getDestroyDependentsCommand
>>>>>> method in this class.
>>>>>>
>>>>>> We need to know if you hit the break point or not ? and if you hit it
>>>>>> did it destroy the views ?
>>>>>>
>>>>>> if you hit the break point and find that
>>>>>> crossReferenceAdapter.getNonNavigableInverseReferences(destr uctee);
>>>>>>
>>>>>> returns empty or incomplete set then most probably the resources
>>>>>> containing your views are not loaded yet. If this is the case the
>>>>>> default implementation of the canonical edit policy will not help you
>>>>>> (I can explain later if we confirm this is the case).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Fabio Centineo wrote:
>>>>>>> Hi,
>>>>>>> I have a custom view in which are displayed the model elements of all
>>>>>>> my editors (these editors shared the same model resource by using the
>>>>>>> same editing domain). From this view I can execute drag and drop of
>>>>>>> elements into my editors. Moreover I can remove elements from the
>>>>>>> model resource through an action on my custom view (by the use of the
>>>>>>> DestroyElementCommand). But I don't know what I have to do in order
>>>>>>> to refresh the editors (which contain orphan element views after the
>>>>>>> remove action executed in the custom view) without reopening them.
>>>>>>> I made some attempts on the editPart of the diagram container
>>>>>>> element, but without success.
>>>>>>> Any suggestion ?
>>>>>>>
>>>>>>> Thanks in advance.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Fabio.
>>>>>>>
>>>>>>>
>
|
|
|
| Re: How can remove orphan views without reopening the editor [message #77536 is a reply to message #77467] |
Tue, 14 November 2006 12:50 |
| Eclipse User |
|
|
|
Hi Mohammed,
thanks a lot for your help.
> The way get element works is, when get element is called on any view, the
> view will check if the element feature is set or not; if it is not set it
> will just forward the call to the container of the view.
>
> This might be the case here, you can put a break point in
> ViewImpl#getElement to see if it is returning different element just
> because the element is unset or not.
Yes, I noticed it by making debug into the handleNotificationEvent method of
the ??EditPart.
The javadoc of the deleteViews() method of the CanonicalEditPolicy class
says that this method
deletes a list of view and the views will be deleted iff their semantic
element has also been deleted.
But the shouldDeleteView() method of my ??CanonicalEditPolicy invoked by it,
returns true only if
view.isSetElement() return true
&&
view.getElement() != null return true
&&
view.getElement().eIsProxy() return true
In my case instead:
view.isSetElement() ==> false
&&
view.getElement() != null ==> true (the element is the container element)
&&
view.getElement().eIsProxy() ==> false
Does it make my change in the shouldDeleteView() correct ?
protected boolean shouldDeleteView(View view)
{
if(view.getElement() instanceof PModel) //PModel is my container element
return true;
return view.isSetElement() && view.getElement() != null &&
view.getElement().eIsProxy();
}
With this change the refresh works correctly.
But I have a doubt: If the element of a view is null (this makes this view
as orphan), could it be better to insert a method (like the
shouldDeleteView() one) that return true if a view has a null element
instead of setting this element with the container element (for which the
shouldDeleteView() returns false) ?
What do you think about ?
Thanks again.
Best regards,
Fabio.
> regarding deleting views in canonical edit policies, some people try to
> avoid this as much as they can since it had one side effect, which is soon
> as you open your diagram the model will be dirty which might not be
> expected by users of your diagram.
>
> I would think that the best way to handle this case will be using
> ElementType or a TriggerListener. If you are ok with the fact that you
> diagram will be dirtied during opening the editor then the canonical edit
> policy approach might be acceptable but keep in mind the view will stay in
> your model till some one open the diagram.
>
>
>
>
>
>
> Fabio Centineo wrote:
>> Hi Linda,
>> sorry for my late reply, I had a lot to do ;-((.
>> The command is null, e thus I can't execute it.
>>
>> A very strange case happens: if I have a diagram with an element view, If
>> I delete this element view from my custom view, the element of the view
>> becomes the container element of the diagram, in fact the displayed name
>> of the element view in the diagram is that of the container element of
>> the diagram.
>> It seems that somewhere the element of the view is setted with the
>> container element of the diagram.
>> The above situation is the main problem for which the refresh methods of
>> the diagram don't work: the view into the diagram is an orphan one, but
>> as its element is the element container, is it impossible to delete it.
>> Only if the diagram is closed and reopened is it possible execute a
>> refresh operation.
>> In order to solve this problem, in my custom view I use my first
>> DestroyElementCommand and in the CanonicalEditPolicy of the delement
>> container, I modified the method shouldDeleteView:
>>
>> protected boolean shouldDeleteView(View view)
>> {
>> if(view.getElement() instanceof PModel) //Note: PModel is the
>> container element of the diagram.
>> return true;
>>
>> return view.isSetElement() && view.getElement() != null &&
>> view.getElement().eIsProxy();
>> }
>>
>> Now, so I have a IPartListener installed on my editor, when the editor is
>> activated, I call the refresh method of its CanonicalEditPolicy, and the
>> diagram is refreshed :-)).
>>
>> What do you think about ? Have I to procede in a different a more correct
>> way ?
>>
>> Thanks again.
>>
>> Best regards,
>> Fabio.
>>
>>
>>
>> "Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
>> news:ej2cih$lat$1@utils.eclipse.org...
>>> Fabio,
>>>
>>> Your code looks correct to me (just remember to check that the command
>>> isn't null and is executable before executing on the operation history -
>>> I should have put that in my original snippet :-)).
>>>
>>> When you compare the delete case that works (using the keyboard on the
>>> diagram?) with the one that doesn't (from your custom view), is it the
>>> same kind of eObject in the same kind of container that is being
>>> deleted?
>>>
>>> Fabio Centineo wrote:
>>>> Hi Linda,
>>>> thank you so much for your reply.
>>>> The source code I implemented is the following:
>>>>
>>>> DestroyElementRequest destroy = new
>>>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>>>> IElementType type =
>>>> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
>>>> ICommand command = (type != null) ? type.getEditCommand(destroy) :
>>>> null;
>>>> try {
>>>> OperationHistoryFactory.getOperationHistory().execute(comman d,
>>>> new NullProgressMonitor(), null);
>>>> }
>>>> catch(ExecutionException e)
>>>> {
>>>> e.printStackTrace();
>>>> }
>>>>
>>>> Is this right ?
>>>> I followed the whole process through debug, but a problem occurs: the
>>>> ICompositeCommand builded inside the method
>>>> getEditCommand() of the AbstractEditHelper class is empty. All the
>>>> followed commands are null:
>>>>
>>>> ICommand beforeAdvice = nextAdvice.getBeforeEditCommand(req);
>>>> ICommand insteadCommand = getInsteadCommand(req);
>>>> ICommand afterAdvice = nextAdvice.getAfterEditCommand(req);
>>>>
>>>> As a result, the command inside the
>>>> OperationHistoryFactory.getOperationHistory().execute(comman d, new
>>>> NullProgressMonitor(), null) method is
>>>> a null command.
>>>> This doesn't happen if I delete an element by means of the canc button
>>>> for which the ICommand insteadCommand = getInsteadCommand(req);
>>>> is a not null command.
>>>> What should I do? Did I forget to do anything?
>>>>
>>>> Thanks again for your help.
>>>>
>>>> Best regards,
>>>> Fabio.
>>>>
>>>>
>>>> "Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
>>>> news:ej21ds$p7v$1@utils.eclipse.org...
>>>>> Fabio,
>>>>>
>>>>> Try
>>>>> IElementType type =
>>>>> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
>>>>> ICommand command = (type != null) ?
>>>>> type.getEditCommand(completedRequest) : null;
>>>>> OperationHistoryFactory.getOperationHistory().execute(comman d, new
>>>>> NullProgressMonitor(), null);
>>>>>
>>>>> from your action instead of creating a new destroy command manually.
>>>>>
>>>>> When you instantiate the command yourself you won't get the advice
>>>>> (such as NotationViewDependentsAdvice) that is contributed via the
>>>>> elementTypes extension point.
>>>>>
>>>>> Fabio Centineo wrote:
>>>>>> Hi Mohammed,
>>>>>> thank you so much for your reply.
>>>>>> In the NotationViewDependentsAdvice class the only present method is
>>>>>> the getBeforeDestroyDependentsCommand (Did you refer to it ?).
>>>>>> If I put a break point in this method, this break point is hit only
>>>>>> if I delete an element by means of the canc button, but it doesn't
>>>>>> hit if I delete an element
>>>>>> from my custom view. The run method of the action in my custom view
>>>>>> is the following:
>>>>>>
>>>>>> public void run() {
>>>>>> ISelection selection = viewer.getSelection();
>>>>>> Object obj = ((IStructuredSelection)selection).getFirstElement();
>>>>>> if(! (obj instanceof PModel) && (obj instanceof EObject) {
>>>>>> final EObject eObject = (EObject)obj;
>>>>>> Resource resource = eObject.eResource();
>>>>>> if (resource != null) {
>>>>>> DestroyElementRequest destroy = new
>>>>>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>>>>>> ICommand command = new DestroyElementCommand(destroy);
>>>>>> try {
>>>>>> command.execute(new NullProgressMonitor(), null);
>>>>>> }
>>>>>> catch(ExecutionException e) {
>>>>>> e.printStackTrace();
>>>>>> }
>>>>>> try {
>>>>>> resource.save(Collections.EMPTY_MAP);
>>>>>> showMessage("Element has been removed!");
>>>>>> }
>>>>>> catch (IOException e) {
>>>>>> return ;
>>>>>> }
>>>>>> .......
>>>>>>
>>>>>> A strange thing happens after I delete an element from my custom
>>>>>> view: the name of the element view into the diagram becames the name
>>>>>> of the container element of the diagram (the root of my custom view).
>>>>>> Moreover, I added a IPartListener on my editor in order to update my
>>>>>> custom view to reflect the model elements of the project that own
>>>>>> that editor (in each project there is an unique model through the
>>>>>> same editing domain). If the activated editor is an editor of another
>>>>>> project, I update my custom view.
>>>>>> I hope to call an update operation of the diagram here, inside the
>>>>>> partActivated method.
>>>>>> But I don't know what operation is made when I close and thus reopen
>>>>>> the diagram. This operation is what I'm looking for.
>>>>>> Have I to make anything with the model resource ? or Have I to make a
>>>>>> forced refresh of the diagram ?
>>>>>>
>>>>>> Thanks again.
>>>>>>
>>>>>> Best regards,
>>>>>> Fabio.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> "Mohammed Mostafa" <mmostafa@ca.ibm.com> ha scritto nel messaggio
>>>>>> news:eivm60$q4g$1@utils.eclipse.org...
>>>>>>> Hi Fabio;
>>>>>>>
>>>>>>> When you delete a semantic element all views, currently in memory,
>>>>>>> pointing to this semantic element are supposed to be deleted.
>>>>>>> This is done in the NotationViewDependentsAdvice class
>>>>>>> I suggest putting a break point in the getDestroyDependentsCommand
>>>>>>> method in this class.
>>>>>>>
>>>>>>> We need to know if you hit the break point or not ? and if you hit
>>>>>>> it did it destroy the views ?
>>>>>>>
>>>>>>> if you hit the break point and find that
>>>>>>> crossReferenceAdapter.getNonNavigableInverseReferences(destr uctee);
>>>>>>>
>>>>>>> returns empty or incomplete set then most probably the resources
>>>>>>> containing your views are not loaded yet. If this is the case the
>>>>>>> default implementation of the canonical edit policy will not help
>>>>>>> you (I can explain later if we confirm this is the case).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Fabio Centineo wrote:
>>>>>>>> Hi,
>>>>>>>> I have a custom view in which are displayed the model elements of
>>>>>>>> all my editors (these editors shared the same model resource by
>>>>>>>> using the same editing domain). From this view I can execute drag
>>>>>>>> and drop of elements into my editors. Moreover I can remove
>>>>>>>> elements from the model resource through an action on my custom
>>>>>>>> view (by the use of the DestroyElementCommand). But I don't know
>>>>>>>> what I have to do in order to refresh the editors (which contain
>>>>>>>> orphan element views after the remove action executed in the custom
>>>>>>>> view) without reopening them.
>>>>>>>> I made some attempts on the editPart of the diagram container
>>>>>>>> element, but without success.
>>>>>>>> Any suggestion ?
>>>>>>>>
>>>>>>>> Thanks in advance.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Fabio.
>>>>>>>>
>>>>>>>>
>>
|
|
|
| Re: How can remove orphan views without reopening the editor [message #77567 is a reply to message #77455] |
Tue, 14 November 2006 13:02 |
| Eclipse User |
|
|
|
Hi Cherie,
thank a lot for your help.
I wrote my doubts to Mostafa, please take a look.
Thanks again.
Best regards,
Fabio.
"Cherie Revells" <crevells@ca.ibm.com> ha scritto nel messaggio
news:ejcm8n$iq4$1@utils.eclipse.org...
> Fabio,
>
> Linda and I were discussing your issue. You shouldn't need to do what you
> are doing to refresh the diagram. Here are some things to consider...
>
> 1. As Linda suggested, I think you should compare how the delete command
> differs when the delete is triggered from the diagram and when it is
> triggered from your custom view. Try putting a breakpoint in the
> SemanticEditPolicy generated for the element that will get deleted to see
> how the delete command is constructed.
>
> 1. If you are deleting the element from your custom view, and the view of
> the element on the diagram is being updated with the name of the container
> element, then your diagram IS responding to the deletion of the element
> (just not in the way that you want). I would suggest putting a breakpoint
> in these locations to try to figure out what is going on:
> - in the handleNotificationEvent() method of the editpart class
> representing the element on the diagram and the editpart class of its name
> label editpart
> - in the notifyChanged() method of your canonical editpolicy.
>
> 3. When you open a diagram editor, if it has a CanonicalEditPolicy
> installed, its activate() method will be called which should refresh the
> diagram. In other words, you shouldn't need to add any special listeners
> in this case.
>
> I hope this helps.
>
> - Cherie
>
> Fabio Centineo wrote:
>> Hi Linda,
>> sorry for my late reply, I had a lot to do ;-((.
>> The command is null, e thus I can't execute it.
>>
>> A very strange case happens: if I have a diagram with an element view, If
>> I delete this element view from my custom view, the element of the view
>> becomes the container element of the diagram, in fact the displayed name
>> of the element view in the diagram is that of the container element of
>> the diagram.
>> It seems that somewhere the element of the view is setted with the
>> container element of the diagram.
>> The above situation is the main problem for which the refresh methods of
>> the diagram don't work: the view into the diagram is an orphan one, but
>> as its element is the element container, is it impossible to delete it.
>> Only if the diagram is closed and reopened is it possible execute a
>> refresh operation.
>> In order to solve this problem, in my custom view I use my first
>> DestroyElementCommand and in the CanonicalEditPolicy of the delement
>> container, I modified the method shouldDeleteView:
>>
>> protected boolean shouldDeleteView(View view)
>> {
>> if(view.getElement() instanceof PModel) //Note: PModel is the
>> container element of the diagram.
>> return true;
>>
>> return view.isSetElement() && view.getElement() != null &&
>> view.getElement().eIsProxy();
>> }
>>
>> Now, so I have a IPartListener installed on my editor, when the editor is
>> activated, I call the refresh method of its CanonicalEditPolicy, and the
>> diagram is refreshed :-)).
>>
>> What do you think about ? Have I to procede in a different a more correct
>> way ?
>>
>> Thanks again.
>>
>> Best regards,
>> Fabio.
>>
>>
>>
>> "Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
>> news:ej2cih$lat$1@utils.eclipse.org...
>>> Fabio,
>>>
>>> Your code looks correct to me (just remember to check that the command
>>> isn't null and is executable before executing on the operation history -
>>> I should have put that in my original snippet :-)).
>>>
>>> When you compare the delete case that works (using the keyboard on the
>>> diagram?) with the one that doesn't (from your custom view), is it the
>>> same kind of eObject in the same kind of container that is being
>>> deleted?
>>>
>>> Fabio Centineo wrote:
>>>> Hi Linda,
>>>> thank you so much for your reply.
>>>> The source code I implemented is the following:
>>>>
>>>> DestroyElementRequest destroy = new
>>>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>>>> IElementType type =
>>>> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
>>>> ICommand command = (type != null) ? type.getEditCommand(destroy) :
>>>> null;
>>>> try {
>>>> OperationHistoryFactory.getOperationHistory().execute(comman d,
>>>> new NullProgressMonitor(), null);
>>>> }
>>>> catch(ExecutionException e)
>>>> {
>>>> e.printStackTrace();
>>>> }
>>>>
>>>> Is this right ?
>>>> I followed the whole process through debug, but a problem occurs: the
>>>> ICompositeCommand builded inside the method
>>>> getEditCommand() of the AbstractEditHelper class is empty. All the
>>>> followed commands are null:
>>>>
>>>> ICommand beforeAdvice = nextAdvice.getBeforeEditCommand(req);
>>>> ICommand insteadCommand = getInsteadCommand(req);
>>>> ICommand afterAdvice = nextAdvice.getAfterEditCommand(req);
>>>>
>>>> As a result, the command inside the
>>>> OperationHistoryFactory.getOperationHistory().execute(comman d, new
>>>> NullProgressMonitor(), null) method is
>>>> a null command.
>>>> This doesn't happen if I delete an element by means of the canc button
>>>> for which the ICommand insteadCommand = getInsteadCommand(req);
>>>> is a not null command.
>>>> What should I do? Did I forget to do anything?
>>>>
>>>> Thanks again for your help.
>>>>
>>>> Best regards,
>>>> Fabio.
>>>>
>>>>
>>>> "Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
>>>> news:ej21ds$p7v$1@utils.eclipse.org...
>>>>> Fabio,
>>>>>
>>>>> Try
>>>>> IElementType type =
>>>>> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
>>>>> ICommand command = (type != null) ?
>>>>> type.getEditCommand(completedRequest) : null;
>>>>> OperationHistoryFactory.getOperationHistory().execute(comman d, new
>>>>> NullProgressMonitor(), null);
>>>>>
>>>>> from your action instead of creating a new destroy command manually.
>>>>>
>>>>> When you instantiate the command yourself you won't get the advice
>>>>> (such as NotationViewDependentsAdvice) that is contributed via the
>>>>> elementTypes extension point.
>>>>>
>>>>> Fabio Centineo wrote:
>>>>>> Hi Mohammed,
>>>>>> thank you so much for your reply.
>>>>>> In the NotationViewDependentsAdvice class the only present method is
>>>>>> the getBeforeDestroyDependentsCommand (Did you refer to it ?).
>>>>>> If I put a break point in this method, this break point is hit only
>>>>>> if I delete an element by means of the canc button, but it doesn't
>>>>>> hit if I delete an element
>>>>>> from my custom view. The run method of the action in my custom view
>>>>>> is the following:
>>>>>>
>>>>>> public void run() {
>>>>>> ISelection selection = viewer.getSelection();
>>>>>> Object obj = ((IStructuredSelection)selection).getFirstElement();
>>>>>> if(! (obj instanceof PModel) && (obj instanceof EObject) {
>>>>>> final EObject eObject = (EObject)obj;
>>>>>> Resource resource = eObject.eResource();
>>>>>> if (resource != null) {
>>>>>> DestroyElementRequest destroy = new
>>>>>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>>>>>> ICommand command = new DestroyElementCommand(destroy);
>>>>>> try {
>>>>>> command.execute(new NullProgressMonitor(), null);
>>>>>> }
>>>>>> catch(ExecutionException e) {
>>>>>> e.printStackTrace();
>>>>>> }
>>>>>> try {
>>>>>> resource.save(Collections.EMPTY_MAP);
>>>>>> showMessage("Element has been removed!");
>>>>>> }
>>>>>> catch (IOException e) {
>>>>>> return ;
>>>>>> }
>>>>>> .......
>>>>>>
>>>>>> A strange thing happens after I delete an element from my custom
>>>>>> view: the name of the element view into the diagram becames the name
>>>>>> of the container element of the diagram (the root of my custom view).
>>>>>> Moreover, I added a IPartListener on my editor in order to update my
>>>>>> custom view to reflect the model elements of the project that own
>>>>>> that editor (in each project there is an unique model through the
>>>>>> same editing domain). If the activated editor is an editor of another
>>>>>> project, I update my custom view.
>>>>>> I hope to call an update operation of the diagram here, inside the
>>>>>> partActivated method.
>>>>>> But I don't know what operation is made when I close and thus reopen
>>>>>> the diagram. This operation is what I'm looking for.
>>>>>> Have I to make anything with the model resource ? or Have I to make a
>>>>>> forced refresh of the diagram ?
>>>>>>
>>>>>> Thanks again.
>>>>>>
>>>>>> Best regards,
>>>>>> Fabio.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> "Mohammed Mostafa" <mmostafa@ca.ibm.com> ha scritto nel messaggio
>>>>>> news:eivm60$q4g$1@utils.eclipse.org...
>>>>>>> Hi Fabio;
>>>>>>>
>>>>>>> When you delete a semantic element all views, currently in memory,
>>>>>>> pointing to this semantic element are supposed to be deleted.
>>>>>>> This is done in the NotationViewDependentsAdvice class
>>>>>>> I suggest putting a break point in the getDestroyDependentsCommand
>>>>>>> method in this class.
>>>>>>>
>>>>>>> We need to know if you hit the break point or not ? and if you hit
>>>>>>> it did it destroy the views ?
>>>>>>>
>>>>>>> if you hit the break point and find that
>>>>>>> crossReferenceAdapter.getNonNavigableInverseReferences(destr uctee);
>>>>>>>
>>>>>>> returns empty or incomplete set then most probably the resources
>>>>>>> containing your views are not loaded yet. If this is the case the
>>>>>>> default implementation of the canonical edit policy will not help
>>>>>>> you (I can explain later if we confirm this is the case).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Fabio Centineo wrote:
>>>>>>>> Hi,
>>>>>>>> I have a custom view in which are displayed the model elements of
>>>>>>>> all my editors (these editors shared the same model resource by
>>>>>>>> using the same editing domain). From this view I can execute drag
>>>>>>>> and drop of elements into my editors. Moreover I can remove
>>>>>>>> elements from the model resource through an action on my custom
>>>>>>>> view (by the use of the DestroyElementCommand). But I don't know
>>>>>>>> what I have to do in order to refresh the editors (which contain
>>>>>>>> orphan element views after the remove action executed in the custom
>>>>>>>> view) without reopening them.
>>>>>>>> I made some attempts on the editPart of the diagram container
>>>>>>>> element, but without success.
>>>>>>>> Any suggestion ?
>>>>>>>>
>>>>>>>> Thanks in advance.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Fabio.
>>>>>>>>
>>>>>>>>
>>
|
|
|
| Re: How can remove orphan views without reopening the editor [message #78006 is a reply to message #77536] |
Wed, 15 November 2006 14:04 |
| Eclipse User |
|
|
|
Hi Fabio ;
Changing shoulddeleteview in your canonical edit policy is your call, i
would not go with this approach my self because i do not like the fact
that it will dirty the model on diagram open and the diagram will be
semantically in correct till it get opened, I'll go with the element
type or the TriggerListener or even a resource listener approach to make
sure that the view will be deleted as soon as the semantic element is
deleted
if you send us a piece of code that simulate your use case we might be
able to debug it and check why Element Type is not working for you
The Element feature is unsettable feature, so if view's element is
unset this does is not the same as saying that the view element is NULL.
if you want to make the view element NULL then you should set it to NULL
; this will make the element feature set and the value = null
If you want to get the actual value of the element feature on the view
and avoid going up to the parent you can call
view.eGet and pass it the NotationPackage.VIEW__ELEMENT as the feature
and false for the resolve flag
Regarding should delete view, the implementation of should delete view
depends on the semantic manning, so i do not think it should be
implemented on the view level.
Fabio Centineo wrote:
> Hi Mohammed,
> thanks a lot for your help.
>
>> The way get element works is, when get element is called on any view, the
>> view will check if the element feature is set or not; if it is not set it
>> will just forward the call to the container of the view.
>>
>> This might be the case here, you can put a break point in
>> ViewImpl#getElement to see if it is returning different element just
>> because the element is unset or not.
>
> Yes, I noticed it by making debug into the handleNotificationEvent method of
> the ??EditPart.
> The javadoc of the deleteViews() method of the CanonicalEditPolicy class
> says that this method
> deletes a list of view and the views will be deleted iff their semantic
> element has also been deleted.
> But the shouldDeleteView() method of my ??CanonicalEditPolicy invoked by it,
> returns true only if
>
> view.isSetElement() return true
> &&
> view.getElement() != null return true
> &&
> view.getElement().eIsProxy() return true
>
> In my case instead:
>
> view.isSetElement() ==> false
> &&
> view.getElement() != null ==> true (the element is the container element)
> &&
> view.getElement().eIsProxy() ==> false
>
> Does it make my change in the shouldDeleteView() correct ?
>
> protected boolean shouldDeleteView(View view)
> {
> if(view.getElement() instanceof PModel) //PModel is my container element
> return true;
>
> return view.isSetElement() && view.getElement() != null &&
> view.getElement().eIsProxy();
> }
>
> With this change the refresh works correctly.
>
> But I have a doubt: If the element of a view is null (this makes this view
> as orphan), could it be better to insert a method (like the
> shouldDeleteView() one) that return true if a view has a null element
> instead of setting this element with the container element (for which the
> shouldDeleteView() returns false) ?
> What do you think about ?
>
> Thanks again.
>
> Best regards,
> Fabio.
>
>
>> regarding deleting views in canonical edit policies, some people try to
>> avoid this as much as they can since it had one side effect, which is soon
>> as you open your diagram the model will be dirty which might not be
>> expected by users of your diagram.
>>
>> I would think that the best way to handle this case will be using
>> ElementType or a TriggerListener. If you are ok with the fact that you
>> diagram will be dirtied during opening the editor then the canonical edit
>> policy approach might be acceptable but keep in mind the view will stay in
>> your model till some one open the diagram.
>>
>>
>>
>>
>>
>>
>> Fabio Centineo wrote:
>>> Hi Linda,
>>> sorry for my late reply, I had a lot to do ;-((.
>>> The command is null, e thus I can't execute it.
>>>
>>> A very strange case happens: if I have a diagram with an element view, If
>>> I delete this element view from my custom view, the element of the view
>>> becomes the container element of the diagram, in fact the displayed name
>>> of the element view in the diagram is that of the container element of
>>> the diagram.
>>> It seems that somewhere the element of the view is setted with the
>>> container element of the diagram.
>>> The above situation is the main problem for which the refresh methods of
>>> the diagram don't work: the view into the diagram is an orphan one, but
>>> as its element is the element container, is it impossible to delete it.
>>> Only if the diagram is closed and reopened is it possible execute a
>>> refresh operation.
>>> In order to solve this problem, in my custom view I use my first
>>> DestroyElementCommand and in the CanonicalEditPolicy of the delement
>>> container, I modified the method shouldDeleteView:
>>>
>>> protected boolean shouldDeleteView(View view)
>>> {
>>> if(view.getElement() instanceof PModel) //Note: PModel is the
>>> container element of the diagram.
>>> return true;
>>>
>>> return view.isSetElement() && view.getElement() != null &&
>>> view.getElement().eIsProxy();
>>> }
>>>
>>> Now, so I have a IPartListener installed on my editor, when the editor is
>>> activated, I call the refresh method of its CanonicalEditPolicy, and the
>>> diagram is refreshed :-)).
>>>
>>> What do you think about ? Have I to procede in a different a more correct
>>> way ?
>>>
>>> Thanks again.
>>>
>>> Best regards,
>>> Fabio.
>>>
>>>
>>>
>>> "Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
>>> news:ej2cih$lat$1@utils.eclipse.org...
>>>> Fabio,
>>>>
>>>> Your code looks correct to me (just remember to check that the command
>>>> isn't null and is executable before executing on the operation history -
>>>> I should have put that in my original snippet :-)).
>>>>
>>>> When you compare the delete case that works (using the keyboard on the
>>>> diagram?) with the one that doesn't (from your custom view), is it the
>>>> same kind of eObject in the same kind of container that is being
>>>> deleted?
>>>>
>>>> Fabio Centineo wrote:
>>>>> Hi Linda,
>>>>> thank you so much for your reply.
>>>>> The source code I implemented is the following:
>>>>>
>>>>> DestroyElementRequest destroy = new
>>>>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>>>>> IElementType type =
>>>>> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
>>>>> ICommand command = (type != null) ? type.getEditCommand(destroy) :
>>>>> null;
>>>>> try {
>>>>> OperationHistoryFactory.getOperationHistory().execute(comman d,
>>>>> new NullProgressMonitor(), null);
>>>>> }
>>>>> catch(ExecutionException e)
>>>>> {
>>>>> e.printStackTrace();
>>>>> }
>>>>>
>>>>> Is this right ?
>>>>> I followed the whole process through debug, but a problem occurs: the
>>>>> ICompositeCommand builded inside the method
>>>>> getEditCommand() of the AbstractEditHelper class is empty. All the
>>>>> followed commands are null:
>>>>>
>>>>> ICommand beforeAdvice = nextAdvice.getBeforeEditCommand(req);
>>>>> ICommand insteadCommand = getInsteadCommand(req);
>>>>> ICommand afterAdvice = nextAdvice.getAfterEditCommand(req);
>>>>>
>>>>> As a result, the command inside the
>>>>> OperationHistoryFactory.getOperationHistory().execute(comman d, new
>>>>> NullProgressMonitor(), null) method is
>>>>> a null command.
>>>>> This doesn't happen if I delete an element by means of the canc button
>>>>> for which the ICommand insteadCommand = getInsteadCommand(req);
>>>>> is a not null command.
>>>>> What should I do? Did I forget to do anything?
>>>>>
>>>>> Thanks again for your help.
>>>>>
>>>>> Best regards,
>>>>> Fabio.
>>>>>
>>>>>
>>>>> "Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
>>>>> news:ej21ds$p7v$1@utils.eclipse.org...
>>>>>> Fabio,
>>>>>>
>>>>>> Try
>>>>>> IElementType type =
>>>>>> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
>>>>>> ICommand command = (type != null) ?
>>>>>> type.getEditCommand(completedRequest) : null;
>>>>>> OperationHistoryFactory.getOperationHistory().execute(comman d, new
>>>>>> NullProgressMonitor(), null);
>>>>>>
>>>>>> from your action instead of creating a new destroy command manually.
>>>>>>
>>>>>> When you instantiate the command yourself you won't get the advice
>>>>>> (such as NotationViewDependentsAdvice) that is contributed via the
>>>>>> elementTypes extension point.
>>>>>>
>>>>>> Fabio Centineo wrote:
>>>>>>> Hi Mohammed,
>>>>>>> thank you so much for your reply.
>>>>>>> In the NotationViewDependentsAdvice class the only present method is
>>>>>>> the getBeforeDestroyDependentsCommand (Did you refer to it ?).
>>>>>>> If I put a break point in this method, this break point is hit only
>>>>>>> if I delete an element by means of the canc button, but it doesn't
>>>>>>> hit if I delete an element
>>>>>>> from my custom view. The run method of the action in my custom view
>>>>>>> is the following:
>>>>>>>
>>>>>>> public void run() {
>>>>>>> ISelection selection = viewer.getSelection();
>>>>>>> Object obj = ((IStructuredSelection)selection).getFirstElement();
>>>>>>> if(! (obj instanceof PModel) && (obj instanceof EObject) {
>>>>>>> final EObject eObject = (EObject)obj;
>>>>>>> Resource resource = eObject.eResource();
>>>>>>> if (resource != null) {
>>>>>>> DestroyElementRequest destroy = new
>>>>>>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>>>>>>> ICommand command = new DestroyElementCommand(destroy);
>>>>>>> try {
>>>>>>> command.execute(new NullProgressMonitor(), null);
>>>>>>> }
>>>>>>> catch(ExecutionException e) {
>>>>>>> e.printStackTrace();
>>>>>>> }
>>>>>>> try {
>>>>>>> resource.save(Collections.EMPTY_MAP);
>>>>>>> showMessage("Element has been removed!");
>>>>>>> }
>>>>>>> catch (IOException e) {
>>>>>>> return ;
>>>>>>> }
>>>>>>> .......
>>>>>>>
>>>>>>> A strange thing happens after I delete an element from my custom
>>>>>>> view: the name of the element view into the diagram becames the name
>>>>>>> of the container element of the diagram (the root of my custom view).
>>>>>>> Moreover, I added a IPartListener on my editor in order to update my
>>>>>>> custom view to reflect the model elements of the project that own
>>>>>>> that editor (in each project there is an unique model through the
>>>>>>> same editing domain). If the activated editor is an editor of another
>>>>>>> project, I update my custom view.
>>>>>>> I hope to call an update operation of the diagram here, inside the
>>>>>>> partActivated method.
>>>>>>> But I don't know what operation is made when I close and thus reopen
>>>>>>> the diagram. This operation is what I'm looking for.
>>>>>>> Have I to make anything with the model resource ? or Have I to make a
>>>>>>> forced refresh of the diagram ?
>>>>>>>
>>>>>>> Thanks again.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Fabio.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> "Mohammed Mostafa" <mmostafa@ca.ibm.com> ha scritto nel messaggio
>>>>>>> news:eivm60$q4g$1@utils.eclipse.org...
>>>>>>>> Hi Fabio;
>>>>>>>>
>>>>>>>> When you delete a semantic element all views, currently in memory,
>>>>>>>> pointing to this semantic element are supposed to be deleted.
>>>>>>>> This is done in the NotationViewDependentsAdvice class
>>>>>>>> I suggest putting a break point in the getDestroyDependentsCommand
>>>>>>>> method in this class.
>>>>>>>>
>>>>>>>> We need to know if you hit the break point or not ? and if you hit
>>>>>>>> it did it destroy the views ?
>>>>>>>>
>>>>>>>> if you hit the break point and find that
>>>>>>>> crossReferenceAdapter.getNonNavigableInverseReferences(destr uctee);
>>>>>>>>
>>>>>>>> returns empty or incomplete set then most probably the resources
>>>>>>>> containing your views are not loaded yet. If this is the case the
>>>>>>>> default implementation of the canonical edit policy will not help
>>>>>>>> you (I can explain later if we confirm this is the case).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Fabio Centineo wrote:
>>>>>>>>> Hi,
>>>>>>>>> I have a custom view in which are displayed the model elements of
>>>>>>>>> all my editors (these editors shared the same model resource by
>>>>>>>>> using the same editing domain). From this view I can execute drag
>>>>>>>>> and drop of elements into my editors. Moreover I can remove
>>>>>>>>> elements from the model resource through an action on my custom
>>>>>>>>> view (by the use of the DestroyElementCommand). But I don't know
>>>>>>>>> what I have to do in order to refresh the editors (which contain
>>>>>>>>> orphan element views after the remove action executed in the custom
>>>>>>>>> view) without reopening them.
>>>>>>>>> I made some attempts on the editPart of the diagram container
>>>>>>>>> element, but without success.
>>>>>>>>> Any suggestion ?
>>>>>>>>>
>>>>>>>>> Thanks in advance.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Fabio.
>>>>>>>>>
>>>>>>>>>
>
>
|
|
|
| Re: How can remove orphan views without reopening the editor [message #78516 is a reply to message #78006] |
Fri, 17 November 2006 09:31 |
| Eclipse User |
|
|
|
Hi Mostafa,
thanks a lot for your help.
> Changing shoulddeleteview in your canonical edit policy is your call, i
> would not go with this approach my self because i do not like the fact
> that it will dirty the model on diagram open and the diagram will be
> semantically in correct till it get opened, I'll go with the element type
> or the TriggerListener or even a resource listener approach to make sure
> that the view will be deleted as soon as the semantic element is deleted
I tryed a TriggerListener attached to an editing domain, but its hard to
work with element views inside it.
Probably the best way is to use element type, but as I told to Lisa, the
result command I obtain is null.
> if you send us a piece of code that simulate your use case we might be
> able to debug it and check why Element Type is not working for you
Yes, in the attchment I post the shape example, it simulates exactly my
case.
The following are the main goals I would to reach:
1) in a diagram is it possible to remove only the view of an element (by
the keyboard or the edit men
Attachment: shape.zip
(Size: 461.67KB, Downloaded 127 times)
|
|
|
| Re: How can remove orphan views without reopening the editor [message #80763 is a reply to message #78516] |
Fri, 24 November 2006 11:29 |
| Eclipse User |
|
|
|
Hi Fabio ;
Sorry it took me a while to get back to you
I think i found why when you delete element it does not invoke the
NotationViewDependentsAdvice. This is happening because you return NULL
in the ShapeBaseEditHelper#getDestroyElementCommand
if you change it to return super().getDestroyElementCommand then you
will be able to delete from your custom view and the diagram will
refresh normally with no need to override should delete
Fabio Centineo wrote:
> Hi Mostafa,
> thanks a lot for your help.
>
>> Changing shoulddeleteview in your canonical edit policy is your call, i
>> would not go with this approach my self because i do not like the fact
>> that it will dirty the model on diagram open and the diagram will be
>> semantically in correct till it get opened, I'll go with the element type
>> or the TriggerListener or even a resource listener approach to make sure
>> that the view will be deleted as soon as the semantic element is deleted
>
> I tryed a TriggerListener attached to an editing domain, but its hard to
> work with element views inside it.
> Probably the best way is to use element type, but as I told to Lisa, the
> result command I obtain is null.
>
>> if you send us a piece of code that simulate your use case we might be
>> able to debug it and check why Element Type is not working for you
>
> Yes, in the attchment I post the shape example, it simulates exactly my
> case.
> The following are the main goals I would to reach:
>
> 1) in a diagram is it possible to remove only the view of an element (by
> the keyboard or the edit menù action),
> the element is not deleted from the model (to make this, I overwritten
> the getDestroyElementCommand() method of the
> ??ItemSemanticPolicy classes);
>
> 2) to remove an element from the model, is it necessary to use the "delete
> from model" action of my custom view
> , represented by the ModelView class. In this action, I commented the
> command that uses element type and I use
> a DestroyElementCommand builded by hand. Please, take a look at the
> first one.
>
> 3) when an element is removed from the model, all the open editors that use
> that element have to update (to make this,
> I modified the shouldDeleteView() method, as I told you).
>
> All diagrams inside a project, work with a shared editing domain, and when
> some change is made only the current diagram
> is marked as dirty.
> The situation of the connections is more complicated: I cannot avoid to
> display a connection between two elements, when this
> connection is still in the model but not displayed in a diagram. I would
> avoid this situation when I open the diagram,
> but it is ok when I execute the drag and drop of the two elements in another
> diagram (in which the connection is automatically
> displayed). But for this last case, I don't know what command is used and
> where this command is launched.
> Moreover, I cannot avoid the drag and drop of connections.
>
> Take into account my model is more complicated than the shape one, and
> strictly extends
> the UML. For example I don't know the reason for which I can't remove only
> the view of a connection,
> whereas in the shape example I'm able to make it.
>
>> The Element feature is unsettable feature, so if view's element is unset
>> this does is not the same as saying that the view element is NULL. if you
>> want to make the view element NULL then you should set it to NULL ; this
>> will make the element feature set and the value = null
>
> No, I don't want that the view's element is null, but since its becomes the
> container element, is it impossible to remove the orphan view with a refresh
> operation. Is it necessary to close and reopen the diagram.
>
>
> Thanks again for the time you spent for me.
>
> Best regards,
> Fabio.
>
>
>
> "Mohammed Mostafa" <mmostafa@ca.ibm.com> ha scritto nel messaggio
> news:ejfoe7$5df$1@utils.eclipse.org...
>> Hi Fabio ;
>>
>> Changing shoulddeleteview in your canonical edit policy is your call, i
>> would not go with this approach my self because i do not like the fact
>> that it will dirty the model on diagram open and the diagram will be
>> semantically in correct till it get opened, I'll go with the element
>> type or the TriggerListener or even a resource listener approach to make
>> sure that the view will be deleted as soon as the semantic element is
>> deleted
>>
>> if you send us a piece of code that simulate your use case we might be
>> able to debug it and check why Element Type is not working for you
>>
>> The Element feature is unsettable feature, so if view's element is
>> unset this does is not the same as saying that the view element is NULL.
>> if you want to make the view element NULL then you should set it to NULL
>> ; this will make the element feature set and the value = null
>>
>> If you want to get the actual value of the element feature on the view
>> and avoid going up to the parent you can call
>>
>> view.eGet and pass it the NotationPackage.VIEW__ELEMENT as the feature
>> and false for the resolve flag
>>
>> Regarding should delete view, the implementation of should delete view
>> depends on the semantic manning, so i do not think it should be
>> implemented on the view level.
>>
>>
>>
>>
>>
>>
>>
>>
>> Fabio Centineo wrote:
>>> Hi Mohammed,
>>> thanks a lot for your help.
>>>
>>>> The way get element works is, when get element is called on any view,
>>>> the
>>>> view will check if the element feature is set or not; if it is not set
>>>> it
>>>> will just forward the call to the container of the view.
>>>>
>>>> This might be the case here, you can put a break point in
>>>> ViewImpl#getElement to see if it is returning different element just
>>>> because the element is unset or not.
>>> Yes, I noticed it by making debug into the handleNotificationEvent method
>>> of
>>> the ??EditPart.
>>> The javadoc of the deleteViews() method of the CanonicalEditPolicy class
>>> says that this method
>>> deletes a list of view and the views will be deleted iff their semantic
>>> element has also been deleted.
>>> But the shouldDeleteView() method of my ??CanonicalEditPolicy invoked by
>>> it,
>>> returns true only if
>>>
>>> view.isSetElement() return true
>>> &&
>>> view.getElement() != null return true
>>> &&
>>> view.getElement().eIsProxy() return true
>>>
>>> In my case instead:
>>>
>>> view.isSetElement() ==> false
>>> &&
>>> view.getElement() != null ==> true (the element is the container
>>> element)
>>> &&
>>> view.getElement().eIsProxy() ==> false
>>>
>>> Does it make my change in the shouldDeleteView() correct ?
>>>
>>> protected boolean shouldDeleteView(View view)
>>> {
>>> if(view.getElement() instanceof PModel) //PModel is my container
>>> element
>>> return true;
>>>
>>> return view.isSetElement() && view.getElement() != null &&
>>> view.getElement().eIsProxy();
>>> }
>>>
>>> With this change the refresh works correctly.
>>>
>>> But I have a doubt: If the element of a view is null (this makes this
>>> view
>>> as orphan), could it be better to insert a method (like the
>>> shouldDeleteView() one) that return true if a view has a null element
>>> instead of setting this element with the container element (for which the
>>> shouldDeleteView() returns false) ?
>>> What do you think about ?
>>>
>>> Thanks again.
>>>
>>> Best regards,
>>> Fabio.
>>>
>>>
>>>> regarding deleting views in canonical edit policies, some people try to
>>>> avoid this as much as they can since it had one side effect, which is
>>>> soon
>>>> as you open your diagram the model will be dirty which might not be
>>>> expected by users of your diagram.
>>>>
>>>> I would think that the best way to handle this case will be using
>>>> ElementType or a TriggerListener. If you are ok with the fact that you
>>>> diagram will be dirtied during opening the editor then the canonical
>>>> edit
>>>> policy approach might be acceptable but keep in mind the view will stay
>>>> in
>>>> your model till some one open the diagram.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Fabio Centineo wrote:
>>>>> Hi Linda,
>>>>> sorry for my late reply, I had a lot to do ;-((.
>>>>> The command is null, e thus I can't execute it.
>>>>>
>>>>> A very strange case happens: if I have a diagram with an element view,
>>>>> If
>>>>> I delete this element view from my custom view, the element of the view
>>>>> becomes the container element of the diagram, in fact the displayed
>>>>> name
>>>>> of the element view in the diagram is that of the container element of
>>>>> the diagram.
>>>>> It seems that somewhere the element of the view is setted with the
>>>>> container element of the diagram.
>>>>> The above situation is the main problem for which the refresh methods
>>>>> of
>>>>> the diagram don't work: the view into the diagram is an orphan one, but
>>>>> as its element is the element container, is it impossible to delete it.
>>>>> Only if the diagram is closed and reopened is it possible execute a
>>>>> refresh operation.
>>>>> In order to solve this problem, in my custom view I use my first
>>>>> DestroyElementCommand and in the CanonicalEditPolicy of the delement
>>>>> container, I modified the method shouldDeleteView:
>>>>>
>>>>> protected boolean shouldDeleteView(View view)
>>>>> {
>>>>> if(view.getElement() instanceof PModel) //Note: PModel is the
>>>>> container element of the diagram.
>>>>> return true;
>>>>>
>>>>> return view.isSetElement() && view.getElement() != null &&
>>>>> view.getElement().eIsProxy();
>>>>> }
>>>>>
>>>>> Now, so I have a IPartListener installed on my editor, when the editor
>>>>> is
>>>>> activated, I call the refresh method of its CanonicalEditPolicy, and
>>>>> the
>>>>> diagram is refreshed :-)).
>>>>>
>>>>> What do you think about ? Have I to procede in a different a more
>>>>> correct
>>>>> way ?
>>>>>
>>>>> Thanks again.
>>>>>
>>>>> Best regards,
>>>>> Fabio.
>>>>>
>>>>>
>>>>>
>>>>> "Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
>>>>> news:ej2cih$lat$1@utils.eclipse.org...
>>>>>> Fabio,
>>>>>>
>>>>>> Your code looks correct to me (just remember to check that the command
>>>>>> isn't null and is executable before executing on the operation
>>>>>> history -
>>>>>> I should have put that in my original snippet :-)).
>>>>>>
>>>>>> When you compare the delete case that works (using the keyboard on the
>>>>>> diagram?) with the one that doesn't (from your custom view), is it the
>>>>>> same kind of eObject in the same kind of container that is being
>>>>>> deleted?
>>>>>>
>>>>>> Fabio Centineo wrote:
>>>>>>> Hi Linda,
>>>>>>> thank you so much for your reply.
>>>>>>> The source code I implemented is the following:
>>>>>>>
>>>>>>> DestroyElementRequest destroy = new
>>>>>>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>>>>>>> IElementType type =
>>>>>>> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
>>>>>>> ICommand command = (type != null) ? type.getEditCommand(destroy) :
>>>>>>> null;
>>>>>>> try {
>>>>>>>
>>>>>>> OperationHistoryFactory.getOperationHistory().execute(comman d,
>>>>>>> new NullProgressMonitor(), null);
>>>>>>> }
>>>>>>> catch(ExecutionException e)
>>>>>>> {
>>>>>>> e.printStackTrace();
>>>>>>> }
>>>>>>>
>>>>>>> Is this right ?
>>>>>>> I followed the whole process through debug, but a problem occurs: the
>>>>>>> ICompositeCommand builded inside the method
>>>>>>> getEditCommand() of the AbstractEditHelper class is empty. All the
>>>>>>> followed commands are null:
>>>>>>>
>>>>>>> ICommand beforeAdvice = nextAdvice.getBeforeEditCommand(req);
>>>>>>> ICommand insteadCommand = getInsteadCommand(req);
>>>>>>> ICommand afterAdvice = nextAdvice.getAfterEditCommand(req);
>>>>>>>
>>>>>>> As a result, the command inside the
>>>>>>> OperationHistoryFactory.getOperationHistory().execute(comman d, new
>>>>>>> NullProgressMonitor(), null) method is
>>>>>>> a null command.
>>>>>>> This doesn't happen if I delete an element by means of the canc
>>>>>>> button
>>>>>>> for which the ICommand insteadCommand = getInsteadCommand(req);
>>>>>>> is a not null command.
>>>>>>> What should I do? Did I forget to do anything?
>>>>>>>
>>>>>>> Thanks again for your help.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Fabio.
>>>>>>>
>>>>>>>
>>>>>>> "Linda Damus" <ldamus@ca.ibm.com> ha scritto nel messaggio
>>>>>>> news:ej21ds$p7v$1@utils.eclipse.org...
>>>>>>>> Fabio,
>>>>>>>>
>>>>>>>> Try
>>>>>>>> IElementType type =
>>>>>>>> ElementTypeRegistry.getInstance().getElementType(destroy.get EditHelperContext());
>>>>>>>> ICommand command = (type != null) ?
>>>>>>>> type.getEditCommand(completedRequest) : null;
>>>>>>>> OperationHistoryFactory.getOperationHistory().execute(comman d, new
>>>>>>>> NullProgressMonitor(), null);
>>>>>>>>
>>>>>>>> from your action instead of creating a new destroy command manually.
>>>>>>>>
>>>>>>>> When you instantiate the command yourself you won't get the advice
>>>>>>>> (such as NotationViewDependentsAdvice) that is contributed via the
>>>>>>>> elementTypes extension point.
>>>>>>>>
>>>>>>>> Fabio Centineo wrote:
>>>>>>>>> Hi Mohammed,
>>>>>>>>> thank you so much for your reply.
>>>>>>>>> In the NotationViewDependentsAdvice class the only present method
>>>>>>>>> is
>>>>>>>>> the getBeforeDestroyDependentsCommand (Did you refer to it ?).
>>>>>>>>> If I put a break point in this method, this break point is hit only
>>>>>>>>> if I delete an element by means of the canc button, but it doesn't
>>>>>>>>> hit if I delete an element
>>>>>>>>> from my custom view. The run method of the action in my custom view
>>>>>>>>> is the following:
>>>>>>>>>
>>>>>>>>> public void run() {
>>>>>>>>> ISelection selection = viewer.getSelection();
>>>>>>>>> Object obj = ((IStructuredSelection)selection).getFirstElement();
>>>>>>>>> if(! (obj instanceof PModel) && (obj instanceof EObject) {
>>>>>>>>> final EObject eObject = (EObject)obj;
>>>>>>>>> Resource resource = eObject.eResource();
>>>>>>>>> if (resource != null) {
>>>>>>>>> DestroyElementRequest destroy = new
>>>>>>>>> DestroyElementRequest(TransactionUtil.getEditingDomain(resou rce),eObject,false);
>>>>>>>>> ICommand command = new DestroyElementCommand(destroy);
>>>>>>>>> try {
>>>>>>>>> command.execute(new NullProgressMonitor(), null);
>>>>>>>>> }
>>>>>>>>> catch(ExecutionException e) {
>>>>>>>>> e.printStackTrace();
>>>>>>>>> }
>>>>>>>>> try {
>>>>>>>>> resource.save(Collections.EMPTY_MAP);
>>>>>>>>> showMessage("Element has been removed!");
>>>>>>>>> }
>>>>>>>>> catch (IOException e) {
>>>>>>>>> return ;
>>>>>>>>> }
>>>>>>>>> .......
>>>>>>>>>
>>>>>>>>> A strange thing happens after I delete an element from my custom
>>>>>>>>> view: the name of the element view into the diagram becames the
>>>>>>>>> name
>>>>>>>>> of the container element of the diagram (the root of my custom
>>>>>>>>> view).
>>>>>>>>> Moreover, I added a IPartListener on my editor in order to update
>>>>>>>>> my
>>>>>>>>> custom view to reflect the model elements of the project that own
>>>>>>>>> that editor (in each project there is an unique model through the
>>>>>>>>> same editing domain). If the activated editor is an editor of
>>>>>>>>> another
>>>>>>>>> project, I update my custom view.
>>>>>>>>> I hope to call an update operation of the diagram here, inside the
>>>>>>>>> partActivated method.
>>>>>>>>> But I don't know what operation is made when I close and thus
>>>>>>>>> reopen
>>>>>>>>> the diagram. This operation is what I'm looking for.
>>>>>>>>> Have I to make anything with the model resource ? or Have I to make
>>>>>>>>> a
>>>>>>>>> forced refresh of the diagram ?
>>>>>>>>>
>>>>>>>>> Thanks again.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Fabio.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> "Mohammed Mostafa" <mmostafa@ca.ibm.com> ha scritto nel messaggio
>>>>>>>>> news:eivm60$q4g$1@utils.eclipse.org...
>>>>>>>>>> Hi Fabio;
>>>>>>>>>>
>>>>>>>>>> When you delete a semantic element all views, currently in memory,
>>>>>>>>>> pointing to this semantic element are supposed to be deleted.
>>>>>>>>>> This is done in the NotationViewDependentsAdvice class
>>>>>>>>>> I suggest putting a break point in the getDestroyDependentsCommand
>>>>>>>>>> method in this class.
>>>>>>>>>>
>>>>>>>>>> We need to know if you hit the break point or not ? and if you hit
>>>>>>>>>> it did it destroy the views ?
>>>>>>>>>>
>>>>>>>>>> if you hit the break point and find that
>>>>>>>>>> crossReferenceAdapter.getNonNavigableInverseReferences(destr uctee);
>>>>>>>>>>
>>>>>>>>>> returns empty or incomplete set then most probably the resources
>>>>>>>>>> containing your views are not loaded yet. If this is the case the
>>>>>>>>>> default implementation of the canonical edit policy will not help
>>>>>>>>>> you (I can explain later if we confirm this is the case).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Fabio Centineo wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>> I have a custom view in which are displayed the model elements of
>>>>>>>>>>> all my editors (these editors shared the same model resource by
>>>>>>>>>>> using the same editing domain). From this view I can execute drag
>>>>>>>>>>> and drop of elements into my editors. Moreover I can remove
>>>>>>>>>>> elements from the model resource through an action on my custom
>>>>>>>>>>> view (by the use of the DestroyElementCommand). But I don't know
>>>>>>>>>>> what I have to do in order to refresh the editors (which contain
>>>>>>>>>>> orphan element views after the remove action executed in the
>>>>>>>>>>> custom
>>>>>>>>>>> view) without reopening them.
>>>>>>>>>>> I made some attempts on the editPart of the diagram container
>>>>>>>>>>> element, but without success.
>>>>>>>>>>> Any suggestion ?
>>>>>>>>>>>
>>>>>>>>>>> Thanks in advance.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Fabio.
>>>>>>>>>>>
>>>>>>>>>>>
>>>
>
>
|
|
|
| Re: How can remove orphan views without reopening the editor [message #81175 is a reply to message #80763] |
Mon, 27 November 2006 11:35 |
| Eclipse User |
|
|
|
Hi Mostafa,
thanks a lot for your help, now it works very well :-))).
Yes, I have no need to override shouldDeleteView method.
Thanks again.
Best regards,
Fabio.
"Mohammed Mostafa" <mmostafa@ca.ibm.com> ha scritto nel messaggio
news:ek76nv$dtf$1@utils.eclipse.org...
> Hi Fabio ;
>
> Sorry it took me a while to get back to you
>
> I think i found why when you delete element it does not invoke the
> NotationViewDependentsAdvice. This is happening because you return NULL in
> the ShapeBaseEditHelper#getDestroyElementCommand
>
> if you change it to return super().getDestroyElementCommand then you will
> be able to delete from your custom view and the diagram will refresh
> normally with no need to override should delete
>
>
>
>
>
>
> Fabio Centineo wrote:
>> Hi Mostafa,
>> thanks a lot for your help.
>>
>>> Changing shoulddeleteview in your canonical edit policy is your call, i
>>> would not go with this approach my self because i do not like the fact
>>> that it will dirty the model on diagram open and the diagram will be
>>> semantically in correct till it get opened, I'll go with the element
>>> type
>>> or the TriggerListener or even a resource listener approach to make sure
>>> that the view will be deleted as soon as the semantic element is deleted
>>
>> I tryed a TriggerListener attached to an editing domain, but its hard to
>> work with element views inside it.
>> Probably the best way is to use element type, but as I told to Lisa, the
>> result command I obtain is null.
>>
>>> if you send us a piece of code that simulate your use case we might be
>>> able to debug it and check why Element Type is not working for you
>>
>> Yes, in the attchment I post the shape example, it simulates exactly my
>> case.
>> The following are the main goals I would to reach:
>>
>> 1) in a diagram is it possible to remove only the view of an element (by
>> the keyboard or the edit men
|
|
|
Goto Forum:
Current Time: Fri Sep 26 18:50:52 EDT 2025
Powered by FUDForum. Page generated in 0.07238 seconds |
Home