Provoke a rollback while executing a RemoveCommand [message #418523] |
Thu, 17 April 2008 15:48 |
Eclipse User |
|
|
|
Originally posted by: bsu.bergauer.ch
Hello there,
When the RemoveCommand is invoked from my EMF editor, I need to
conditionally pop up a confirm dialog to ask the user for permission
(depending on if there exist non containment references or not). It is
important that this is checked when the RemoveCommand is actually executed,
not when it is created.
After overriding the createRemoveCommand() in the generated ItemProvider of
the containment object, I return an extended RemoveCommand doing this check
in the doExecute() method before calling super.doExecute().
However, as I found out, the only way to stop the CompoundCommand that is
executing the RemoveCommand and get it to roll back, if the user clicks
cancel in the confirm dialog, is to throw a RuntimeException (i.e
UnsupportedOperationException). The CompoundCommand catches the
RuntimeException and rolls back the command chain. Unforunately the
RuntimeException is also resulting in an error dialog which I do not want to
annoy the user with.
Does anyone have a good solution how to solve this problem?
Thanks in advance!
Bjoern Sundin
|
|
|
|
Re: Provoke a rollback while executing a RemoveCommand [message #418546 is a reply to message #418529] |
Fri, 18 April 2008 08:10 |
Eclipse User |
|
|
|
Originally posted by: bsu.bergauer.ch
This is a multi-part message in MIME format.
------=_NextPart_000_000E_01C8A13C.7D44CDF0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Ed and thanks for your fast reply!
Yes, this was a suitable handling of my problem, I had, however, some =
complications in getting to the BasicCommandStack in order to specialize =
it. My app is using two emf editors and one gmf diagram with a shared =
editing domain. As of now, the editing domain is initiated by the =
diagram plugin invoking =
GMFEditingDomainFactory.INSTANCE.createEditingDomain(). By also =
extending the GMFEditingDomainFactory though, this solution worked.
Thanks a lot!
Bjoern
"Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag =
news:fu7svq$99i$1@build.eclipse.org...
Bj=F6rn,
You could specialize the way the exception is handled in the =
BasicCommandStack:
/**
* Handles an exception thrown during command execution by loging =
it with the plugin.
*/
protected void handleError(Exception exception)=20
{
CommonPlugin.INSTANCE.log
(new WrappedException
=
(CommonPlugin.INSTANCE.getString("_UI_IgnoreException_exception "), =
exception).fillInStackTrace());
}
Bj=F6rn Sundin wrote:=20
Hello there,
When the RemoveCommand is invoked from my EMF editor, I need to
conditionally pop up a confirm dialog to ask the user for permission
(depending on if there exist non containment references or not). It is
important that this is checked when the RemoveCommand is actually =
executed,
not when it is created.
After overriding the createRemoveCommand() in the generated ItemProvider =
of
the containment object, I return an extended RemoveCommand doing this =
check
in the doExecute() method before calling super.doExecute().
However, as I found out, the only way to stop the CompoundCommand that =
is
executing the RemoveCommand and get it to roll back, if the user clicks
cancel in the confirm dialog, is to throw a RuntimeException (i.e
UnsupportedOperationException). The CompoundCommand catches the
RuntimeException and rolls back the command chain. Unforunately the
RuntimeException is also resulting in an error dialog which I do not =
want to
annoy the user with.
Does anyone have a good solution how to solve this problem?
Thanks in advance!
Bjoern Sundin
=20
------=_NextPart_000_000E_01C8A13C.7D44CDF0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2800.1528" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Ed and thanks for your fast =
reply!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Yes, this was a suitable handling =
of my=20
problem, I had, however, some complications in getting to the=20
BasicCommandStack in order to specialize it. My app is using two emf =
editors and=20
one gmf diagram with a shared editing domain. As of now, the =
editing domain=20
is initiated by the diagram plugin invoking=20
GMFEditingDomainFactory.INSTANCE.createEditingDomain(). By also =
extending the=20
GMFEditingDomainFactory though, this solution worked.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks a lot!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Bjoern</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
schrieb im Newsbeitrag <A=20
=
href=3D"news:fu7svq$99i$1@build.eclipse.org">news:fu7svq$99i$1@build.ecli=
pse.org</A>...</DIV>Bj=F6rn,<BR><BR>You=20
could specialize the way the exception is handled in the=20
BasicCommandStack:<BR>
<BLOCKQUOTE><SMALL> /**<BR> * Handles an exception =
thrown=20
during command execution by loging it with the =
plugin.<BR> =20
*/<BR> protected void handleError(Exception exception) =
<BR> =20
{<BR> =20
CommonPlugin.INSTANCE.log<BR> (new=20
WrappedException<BR> =
(CommonPlugin.INSTANCE.getString("_UI_IgnoreException_exception "),=20
exception).fillInStackTrace());<BR> =
}</SMALL><BR></BLOCKQUOTE><BR>Bj=F6rn=20
Sundin wrote:=20
<BLOCKQUOTE cite=3Dmid:fu7rga$ilf$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Hello there,
When the RemoveCommand is invoked from my EMF editor, I need to
conditionally pop up a confirm dialog to ask the user for permission
(depending on if there exist non containment references or not). It is
important that this is checked when the RemoveCommand is actually =
executed,
not when it is created.
After overriding the createRemoveCommand() in the generated ItemProvider =
of
the containment object, I return an extended RemoveCommand doing this =
check
in the doExecute() method before calling super.doExecute().
However, as I found out, the only way to stop the CompoundCommand that =
is
executing the RemoveCommand and get it to roll back, if the user clicks
cancel in the confirm dialog, is to throw a RuntimeException (i.e
UnsupportedOperationException). The CompoundCommand catches the
RuntimeException and rolls back the command chain. Unforunately the
RuntimeException is also resulting in an error dialog which I do not =
want to
annoy the user with.
Does anyone have a good solution how to solve this problem?
Thanks in advance!
Bjoern Sundin
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_000E_01C8A13C.7D44CDF0--
|
|
|
Powered by
FUDForum. Page generated in 0.04032 seconds