Home » Eclipse Projects » GEF » Weird CreationTool behaviour
| Weird CreationTool behaviour [message #6840] |
Sun, 02 June 2002 11:04  |
Eclipse User |
|
|
|
Hi
I'm trying to create an applicatino, that one of its editors is similar to
the logic example. i have extanded CreationTool, and for some reason i
can't get the add cursor to apear over the canvas (which is actually an
EditPart) when i select the appropriate entry from the palette. It seems
that the method mouseDrag (implemented in AbstractTool), does not get
called. any ideas what have i done wrong?
thanks
yoav
|
|
| |
| Re: Weird CreationTool behaviour [message #7091 is a reply to message #6891] |
Mon, 03 June 2002 03:08  |
| Eclipse User |
|
|
|
Hi
what do you mean by saying "the editpart sais that it is the target of
this type of creation", how does the tool check this?
moreover, who is suppose to return the appropriate command, as i saw in
the logic example, the method getCommand(Request r) is not implemented in
LogicEditPart, so who is retuning the command there?
thanks
yoav
Randy Hudson wrote:
> The creation tool does not work using mouseDrag. You have to click on the
> palette and release, then you enter a "creation mode", and the tool will
> handle mouseMove.
> Then, you will only get the add cursor if your canvas editpart says that it
> is the target of that type of creation, *and* it returns a command that is
> executable.
> "Yoav Rubin" <yoav@il.ibm.com> wrote in message
> news:addc68$1r9$1@rogue.oti.com...
> > Hi
> > I'm trying to create an applicatino, that one of its editors is similar to
> > the logic example. i have extanded CreationTool, and for some reason i
> > can't get the add cursor to apear over the canvas (which is actually an
> > EditPart) when i select the appropriate entry from the palette. It seems
> > that the method mouseDrag (implemented in AbstractTool), does not get
> > called. any ideas what have i done wrong?
> > thanks
> > yoav
> >
|
|
|
| Re: Weird CreationTool behaviour [message #7113 is a reply to message #7091] |
Mon, 03 June 2002 07:50 |
| Eclipse User |
|
|
|
Originally posted by: none.ibm.com
This is handled by XYLayoutEditPolicy. The diagram itself is in an
XYLayout. The implementation of dropping into this layout is separated out
into an EditPolicy, which your EditPart can then use or not use, if it
wants. If you aren't sure about why this "delegation" is a good idea, the
reasoning is in the JavaDOC overview for GEF.
XYLayoutEditPolicy knows it is the target of CREATION, MOVE, and ADD (add is
when an existing object is changing parents or containers). see
LayoutEditPolicy.getTarget(Request).
"Yoav Rubin" <yoav@il.ibm.com> wrote in message
news:adf4li$f57$1@rogue.oti.com...
> Hi
> what do you mean by saying "the editpart sais that it is the target of
> this type of creation", how does the tool check this?
> moreover, who is suppose to return the appropriate command, as i saw in
> the logic example, the method getCommand(Request r) is not implemented in
> LogicEditPart, so who is retuning the command there?
> thanks
> yoav
> Randy Hudson wrote:
>
|
|
|
| Re: Weird CreationTool behaviour [message #7137 is a reply to message #7113] |
Mon, 03 June 2002 07:59 |
| Eclipse User |
|
|
|
Hi
i\\\'ve extended ContainerEditPolicy, and implemented the methods
getTarget and getCommand. it seems that the method getCommand is called on
every mouseMove event, in this method i am instanciating a command, and i
would prefer that the instanciation would be when i click on the canvas,
rather on every mouse move, am i doing something wrong in this process or
is it the expected behaviour?
thanks
yoav
Randy Hudson wrote:
> This is handled by XYLayoutEditPolicy. The diagram itself is in an
> XYLayout. The implementation of dropping into this layout is separated out
> into an EditPolicy, which your EditPart can then use or not use, if it
> wants. If you aren\\\'t sure about why this \\\"delegation\\\" is a good
idea, the
> reasoning is in the JavaDOC overview for GEF.
> XYLayoutEditPolicy knows it is the target of CREATION, MOVE, and ADD (add is
> when an existing object is changing parents or containers). see
> LayoutEditPolicy.getTarget(Request).
> \\\"Yoav Rubin\\\" <yoav@il.ibm.com> wrote in message
> news:adf4li$f57$1@rogue.oti.com...
> > Hi
> > what do you mean by saying \\\"the editpart sais that it is the target of
> > this type of creation\\\", how does the tool check this?
> > moreover, who is suppose to return the appropriate command, as i saw in
> > the logic example, the method getCommand(Request r) is not implemented in
> > LogicEditPart, so who is retuning the command there?
> > thanks
> > yoav
> > Randy Hudson wrote:
> >
|
|
| |
| Re: Weird CreationTool behaviour [message #7182 is a reply to message #7160] |
Mon, 03 June 2002 09:44 |
| Eclipse User |
|
|
|
Hi
i still can\'t find who suppose to instanciate the EditPart that will be
created due to the selection in the palette I tried to use the method
createChild(Object model) in the canvas editpart, but this method doesn\'t
get called, so who suppose to do this?
as for the getCommand method, is there a way to not have to instanciate a
new command on every mouse move, since this way of action is a bit extreme.
thanks
yoav
Randy Hudson wrote:
> Why extend ContainerEditPolicy? XYLayoutEditPolicy handles creating the
> appropriate Rectangle where the new part is going to be placed.
> ContainerEditPolicy is non-graphical, meaning it doesn\'t really care about
> UI interaction.
> > i\\\\\\\'ve extended ContainerEditPolicy, and implemented the methods
> > getTarget and getCommand. it seems that the method getCommand is called on
> > every mouseMove event, in this method i am instanciating a command, and i
> > would prefer that the instanciation would be when i click on the canvas,
> > rather on every mouse move, am i doing something wrong in this process or
> > is it the expected behaviour?
> This is the expected behavior. Command.canExecute() is used to determine
> whether the NOT cursor should be displayed.
|
|
|
| Re: Weird CreationTool behaviour [message #7205 is a reply to message #7182] |
Mon, 03 June 2002 10:11 |
| Eclipse User |
|
|
|
Originally posted by: none.ibm.com
Put a breakpoint in:
com.ibm.etools.gef.examples.logicdesigner.model.CreateComman d#execute()
and step through the code.
You will see that the EditPart is a listener to the model, it calls
refreshChildren, which eventually calls createChild(Object) when it finds
the new child for which there currently is no EditPart.
"Yoav Rubin" <yoav@il.ibm.com> wrote in message
news:adfrsh$q4o$1@rogue.oti.com...
> Hi
> i still can\'t find who suppose to instanciate the EditPart that will be
> created due to the selection in the palette I tried to use the method
> createChild(Object model) in the canvas editpart, but this method doesn\'t
> get called, so who suppose to do this?
>
> as for the getCommand method, is there a way to not have to instanciate a
> new command on every mouse move, since this way of action is a bit
extreme.
> thanks
> yoav
> Randy Hudson wrote:
>
> > Why extend ContainerEditPolicy? XYLayoutEditPolicy handles creating the
> > appropriate Rectangle where the new part is going to be placed.
>
> > ContainerEditPolicy is non-graphical, meaning it doesn\'t really care
about
> > UI interaction.
>
> > > i\\\\\\\'ve extended ContainerEditPolicy, and implemented the methods
> > > getTarget and getCommand. it seems that the method getCommand is
called on
> > > every mouseMove event, in this method i am instanciating a command,
and i
> > > would prefer that the instanciation would be when i click on the
canvas,
> > > rather on every mouse move, am i doing something wrong in this
process or
> > > is it the expected behaviour?
>
> > This is the expected behavior. Command.canExecute() is used to
determine
> > whether the NOT cursor should be displayed.
>
>
>
>
>
|
|
| | |
Goto Forum:
Current Time: Tue Mar 11 03:01:21 EDT 2025
Powered by FUDForum. Page generated in 0.04377 seconds |
Home