Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » Indicate GEF command did nothing to stack?
Indicate GEF command did nothing to stack? [message #217855] Wed, 14 June 2006 11:28 Go to next message
Eclipse User
Originally posted by: eclipse.chris-lott.org

I am working on a GEF-based editor, including a dialog that pops up to
edit the content of some elements on the GEF diagram. It was relatively
straightforward to string together the action, request, policy, eventually
leading to a command. That command puts up a modal dialog to gather
information from the user.

Now here's the catch. The user can cancel out of the dialog, essentially
aborting the command, which means no changes are saved to the model. But
the eclipse command stack thinks the command did work, and marks the
editor as dirty. I thought that maybe the execute() method could indicate
success/failure, but it doesn't return anything. By my reading of the
CommandStack code, it is NOT appropriate to throw an OperationCanceled
exception.

Has anyone else grappled with this issue?
Re: Indicate GEF command did nothing to stack? [message #217862 is a reply to message #217855] Wed, 14 June 2006 11:52 Go to previous messageGo to next message
Steven R. Shaw is currently offline Steven R. Shaw
Messages: 128
Registered: July 2009
Senior Member
It's best to construct your parameters to the command when the request is
handled by your EditPolicy. i.e. when the request is received, put up the
dialog and then propogate the parameters to your command constructor. You
may have to differentiate between requests sent for enablement purposes
versus real requests to accomplish this.

Otherwise, you are free to override the CommandStack with your own and wrap
the execute(Command command) method with a try / catch that catches the
OperationCanceledException.

i.e.
public void execute(Command command) {
try {
super.execute(command);
}
catch OperationCanceledException e {
// do nothing
}
}

Note: this will be accommodated more specifically when the OperationHistory
framework is adopted by GEF > 3.2.

-Steve

"Chris Lott" <eclipse@chris-lott.org> wrote in message
news:39b59352c263a82e87371a41892549a3$1@www.eclipse.org...
> I am working on a GEF-based editor, including a dialog that pops up to
> edit the content of some elements on the GEF diagram. It was relatively
> straightforward to string together the action, request, policy, eventually
> leading to a command. That command puts up a modal dialog to gather
> information from the user.
>
> Now here's the catch. The user can cancel out of the dialog, essentially
> aborting the command, which means no changes are saved to the model. But
> the eclipse command stack thinks the command did work, and marks the
> editor as dirty. I thought that maybe the execute() method could indicate
> success/failure, but it doesn't return anything. By my reading of the
> CommandStack code, it is NOT appropriate to throw an OperationCanceled
> exception.
>
> Has anyone else grappled with this issue?
>
Re: Indicate GEF command did nothing to stack? [message #217893 is a reply to message #217855] Wed, 14 June 2006 13:13 Go to previous messageGo to next message
Eclipse User
Originally posted by: sunil_kamath.nohotspammail.com

Chris Lott <eclipse@chris-lott.org> wrote:
> I am working on a GEF-based editor, including a dialog that pops up to
> edit the content of some elements on the GEF diagram. It was
> relatively straightforward to string together the action, request,
> policy, eventually leading to a command. That command puts up a
> modal dialog to gather information from the user.
>
> Now here's the catch. The user can cancel out of the dialog,
> essentially aborting the command, which means no changes are saved to
> the model. But the eclipse command stack thinks the command did
> work, and marks the editor as dirty. I thought that maybe the
> execute() method could indicate success/failure, but it doesn't
> return anything. By my reading of the CommandStack code, it is NOT
> appropriate to throw an OperationCanceled exception.
>
> Has anyone else grappled with this issue?

Well, I usually complete any user interaction before I post the command to
the stack.
That way, if the user cancels, nothing changes in the stack.

--
Sunil
Re: Indicate GEF command did nothing to stack? [message #217912 is a reply to message #217862] Wed, 14 June 2006 13:51 Go to previous messageGo to next message
Eclipse User
Originally posted by: eclipse.chris-lott.org

Thank you very much for the fast, useful reply. I moved the
dialog-opening business from the command to the edit policy. I added a
new request type for the enablement check, and extended the edit policy to
return a trivial command in that case with canExecute() always true. So
far this setup works just fine: undo backs out the changes, redo tosses
them back in. And I don't have to wait for GEF 3.2+ :-)

chris...
Re: Indicate GEF command did nothing to stack? [message #218145 is a reply to message #217862] Tue, 20 June 2006 06:08 Go to previous messageGo to next message
Eclipse User
Originally posted by: modica.$nospam$cs.tu-berlin.de

Hi,

I think this isn't appropriate e.g. for creating connections because
everytime you move the mouse the Tool tries to get a new command.
In this case a general solution would be to pop up a dialog just before the
tool executes the command.
You just have to install a derived Tool which contains something like this
in your palette:

@Override
protected void executeCurrentCommand() {
PropertiesDialog d = new PropertiesDialog(shell, SWT.NULL);
// initialize dialog
...
d.open();
if (d.isCancelled()) {
return;
}
super.executeCurrentCommand();
}

Now, if you cancel the dialog nothing is put on the command stack.

"Steven Shaw" <steveshaw@ca.ibm.com> schrieb im Newsbeitrag
news:e6pb6d$9nf$1@utils.eclipse.org...
> It's best to construct your parameters to the command when the request is
> handled by your EditPolicy. i.e. when the request is received, put up the
> dialog and then propogate the parameters to your command constructor. You
> may have to differentiate between requests sent for enablement purposes
> versus real requests to accomplish this.
>
> Otherwise, you are free to override the CommandStack with your own and
> wrap
> the execute(Command command) method with a try / catch that catches the
> OperationCanceledException.
>
> i.e.
> public void execute(Command command) {
> try {
> super.execute(command);
> }
> catch OperationCanceledException e {
> // do nothing
> }
> }
>
> Note: this will be accommodated more specifically when the
> OperationHistory
> framework is adopted by GEF > 3.2.
>
> -Steve
>
> "Chris Lott" <eclipse@chris-lott.org> wrote in message
> news:39b59352c263a82e87371a41892549a3$1@www.eclipse.org...
>> I am working on a GEF-based editor, including a dialog that pops up to
>> edit the content of some elements on the GEF diagram. It was relatively
>> straightforward to string together the action, request, policy,
>> eventually
>> leading to a command. That command puts up a modal dialog to gather
>> information from the user.
>>
>> Now here's the catch. The user can cancel out of the dialog, essentially
>> aborting the command, which means no changes are saved to the model. But
>> the eclipse command stack thinks the command did work, and marks the
>> editor as dirty. I thought that maybe the execute() method could
>> indicate
>> success/failure, but it doesn't return anything. By my reading of the
>> CommandStack code, it is NOT appropriate to throw an OperationCanceled
>> exception.
>>
>> Has anyone else grappled with this issue?
>>
>
>
Re: Indicate GEF command did nothing to stack? [message #218160 is a reply to message #218145] Tue, 20 June 2006 09:32 Go to previous messageGo to next message
Eclipse User
Originally posted by: lamont_gilbert.rigidsoftware.com

No. Change your program so that mouse actions that are not button pushes do
not require a dialog.

Construct the command upfront. And make the UI in such a way that the
completion does not require any user dialog. Perhaps you need to let them
set preferences in the toolbar. But I dont think its standard UI to ask
user questions when no button has been pushed.



Tony Modica wrote:

> Hi,
>
> I think this isn't appropriate e.g. for creating connections because
> everytime you move the mouse the Tool tries to get a new command.
> In this case a general solution would be to pop up a dialog just before
> the tool executes the command.
> You just have to install a derived Tool which contains something like this
> in your palette:
>
> @Override
> protected void executeCurrentCommand() {
> PropertiesDialog d = new PropertiesDialog(shell, SWT.NULL);
> // initialize dialog
> ...
> d.open();
> if (d.isCancelled()) {
> return;
> }
> super.executeCurrentCommand();
> }
>
> Now, if you cancel the dialog nothing is put on the command stack.
>
> "Steven Shaw" <steveshaw@ca.ibm.com> schrieb im Newsbeitrag
> news:e6pb6d$9nf$1@utils.eclipse.org...




--
Respectfully,

CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into the
sheepfold{}, but climbeth up some other *way, the same is a thief and a
robber."
Re: Indicate GEF command did nothing to stack? [message #218174 is a reply to message #217855] Tue, 20 June 2006 09:38 Go to previous messageGo to next message
Eclipse User
Originally posted by: lamont_gilbert.rigidsoftware.com

Chris Lott wrote:

> I am working on a GEF-based editor, including a dialog that pops up to
> edit the content of some elements on the GEF diagram. It was relatively
> straightforward to string together the action, request, policy, eventually
> leading to a command. That command puts up a modal dialog to gather
> information from the user.
>

Sounds like a 'wizard' to me.

> Now here's the catch. The user can cancel out of the dialog, essentially
> aborting the command, which means no changes are saved to the model. But
> the eclipse command stack thinks the command did work, and marks the
> editor as dirty. I thought that maybe the execute() method could indicate
> success/failure, but it doesn't return anything. By my reading of the
> CommandStack code, it is NOT appropriate to throw an OperationCanceled
> exception.
>
> Has anyone else grappled with this issue?

I think you have done this wrong. You don't cancel out of a command, you
undo them. Perhaps what you want was to cancel the construction of the
command. Command should not be executed 1 step at a time with
cancellability in between. If you do your commands like this then you are
fighting Eclipse/GEF architecture.


I started out with some things like this in my app long ago. I created a
connection from one component to another. Then upon 'completion' i popped
up a dialog asking what connection type, what circuit to put inside
connection and a bunch of other stuff. Eventually I changed. Now there is
one tool per connection type so user determines type by which tool he uses.
and circuits can be set afterwards with a seperate action. I think its
much more user friendly and smoother interactino. Users likely don't want
to see too many 'dialogs' in a graphical program.


--
Respectfully,

CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into the
sheepfold{}, but climbeth up some other *way, the same is a thief and a
robber."
Re: Indicate GEF command did nothing to stack? [message #218237 is a reply to message #217855] Tue, 20 June 2006 15:02 Go to previous messageGo to next message
Eclipse User
Originally posted by: eclipse.chris-lott.org

As I wrote a few days ago, thanks to Steven Shaw's reply in this thread, I
figured out how to manage this issue for editing items already in a
diagram: the edit policy pops the dialog and creates an appropriate
command (or not) when the user is done with the dialog. The key there
(again thanks to Mr. Shaw) was that I have a custom action that can
separate enablement from execution. My action controls the request; it
uses one in its calculateEnabled() method, and another in its run()
method.


Today I hit an issue when working on the create (add a new item to a
diagram). If I click on the palette entry to "load" the mouse, then as
I'm moving the mouse over the diagram, the getCreateRequest is sent
repeatedly to check the enablement of the create command. I think this is
what a previous poster in this thread might be referring to -- if you put
the pop-dialog code in the policy this way, the dialog is popped up over
and over and over (and over). Eventually I finally click button 1 to
"unload" the mouse and add the item to the diagram. That is when I'd like
the dialog.


The problem I see today is that I cannot tell the case of checking
enablement apart from the case of creating a new item. The CreateRequest
doesn't indicate via any of its properties whether it's just checking the
enablement (to show visual feedback) or whether the requested command will
actually be run. I've walked up the class hierarchy of
CombinedTemplateCreationEntry, CreationToolEntry, ToolEntry, and
PaletteEntry but I have not figured out what I might override. I thought
maybe I could use the state of AbstractTool to determine whether
enablement is being checked or whether creation actually is done. No luck
yet tho.


I think another poster made a good point about having one item in the
palette for each type of object. However, even with that done, you still
probably have to edit particular properties of a newly created object. A
dialog is one way of accepting and validating those properties, especially
if they are complex and ill suited to showing in a properties view. I
think it is helpful to open that particular dialog before adding a new
object to the diagram; I don't think it's helpful to drop the object in
with default values for all properties and then wait for the user to open
it for edit.


Please tell me what I'm missing. Thanks in advance for all help.


chris...
Re: Indicate GEF command did nothing to stack? [message #218243 is a reply to message #218237] Tue, 20 June 2006 17:02 Go to previous message
Eclipse User
Originally posted by: lamont_gilbert.rigidsoftware.com

Chris Lott wrote:

> As I wrote a few days ago, thanks to Steven Shaw's reply in this thread, I
> figured out how to manage this issue for editing items already in a
> diagram: the edit policy pops the dialog and creates an appropriate
> command (or not) when the user is done with the dialog. The key there
> (again thanks to Mr. Shaw) was that I have a custom action that can
> separate enablement from execution. My action controls the request; it
> uses one in its calculateEnabled() method, and another in its run()
> method.
>
>

I have some like this. Only when I can't avoid it.


> Today I hit an issue when working on the create (add a new item to a
> diagram). If I click on the palette entry to "load" the mouse, then as
> I'm moving the mouse over the diagram, the getCreateRequest is sent
> repeatedly to check the enablement of the create command. I think this is
> what a previous poster in this thread might be referring to -- if you put
> the pop-dialog code in the policy this way, the dialog is popped up over
> and over and over (and over). Eventually I finally click button 1 to
> "unload" the mouse and add the item to the diagram. That is when I'd like
> the dialog.
>
>

(Note: simple way is to put your dialog in the execute part of your action
not the enabled part)

anyway. Thats the architecture. It should be enabled if conditions are
correct to start the creation of your thing. For me its enabled if
conditions are correct for the whole command to succeed. Which is how I
think it should be, but probably after you tangle yourself up enough, youll
back out :D

Users want fast action, not a bunch of menus to create something.

> The problem I see today is that I cannot tell the case of checking
> enablement apart from the case of creating a new item. The CreateRequest
> doesn't indicate via any of its properties whether it's just checking the
> enablement (to show visual feedback) or whether the requested command will
> actually be run. I've walked up the class hierarchy of
> CombinedTemplateCreationEntry, CreationToolEntry, ToolEntry, and
> PaletteEntry but I have not figured out what I might override. I thought
> maybe I could use the state of AbstractTool to determine whether
> enablement is being checked or whether creation actually is done. No luck
> yet tho.
>
>

There should be no difference. Thats the architecture. Im sure you have
many programs on your computer. Try some of the ones that are graphical
and see how many times during creation of something using graphical 'tools'
you are asked to click through a menu.

If you differentiate so-called enablement check from actual execution, then
you will be creating an artificial difference that you will have to
maintain because GEF does not support this. I have been here. I did it
your way first.

> I think another poster made a good point about having one item in the
> palette for each type of object. However, even with that done, you still
> probably have to edit particular properties of a newly created object. A
> dialog is one way of accepting and validating those properties, especially
> if they are complex and ill suited to showing in a properties view. I
> think it is helpful to open that particular dialog before adding a new
> object to the diagram; I don't think it's helpful to drop the object in
> with default values for all properties and then wait for the user to open
> it for edit.
>

Edit properties before you create. Use the tool bar to select, color,
linewidth, line style, etc. Then when you create it uses those properties
from the toolbar.

>
> Please tell me what I'm missing. Thanks in advance for all help.
>
>
> chris...

I feel your pain. But please, no dialogs during mouse creation.
Re-architect your program. I now have things created with missing
components or default components. I have a validation engine that puts
small red dots on the incomplete things. I followed your route for a long
time. Then finally I was done. Then I started to use the program and test
it. Every-single-act- was a dialog asking the same exact question over and
over and over. The monotony!!

So then I understood GEF. So I changed stuff to not ask any questions like
that. and I noticed I started dumping kludge classes left and right as it
fit in with GEF better.

I still have some situations like this. For instance, when I want to delete
a connection. I dont allow deletion of connections that have circuits in
them or that are connected. But the 'hasCircuit' check hits the database.
So I don't want that test every time you select a connection. So for the
action I just check that the connection is not connected. If so, I enable
the action but I don't build a command yet. Then when action is executed I
check the hasCircuit (since i already passed the isConnected test) and if
it has circuit I show an error dialog stating why I cant delete. Else I
let the command do it thing.

Its not perfect because the action kind of assume it knows what the command
needs to run. its good enough.


My changes have come because I got annoyed by my program talking too much.

P.S. I almost forgot how much pain it is to maintain a command sequence that
was put together by a dialog with some commands needing info from prior
commands etc. Which you will need if you want undo.

--
Respectfully,

CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into the
sheepfold{}, but climbeth up some other *way, the same is a thief and a
robber."
Previous Topic:Draw2D and Properties view
Next Topic:Selective SanpToGrid Question
Goto Forum:
  


Current Time: Sat Apr 19 05:53:27 EDT 2014

Powered by FUDForum. Page generated in 0.02345 seconds