Eclipse Community Forums: Graphiti

Help

Home

Home » Modeling » Graphiti » Restricting move

Show: Today's Messages :: Show Polls :: Message Navigator

Restricting move [message #740702]

Tue, 18 October 2011 20:01

Hernan Gonzalez

Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina

Senior Member

I want to impose some restriction to the movement of some shape, eg. allow to move it only vertically. I guessed that preMoveShape() was devised for this kind of thing, but I ended doing something quite dirty:

protected void preMoveShape(IMoveShapeContext context) {
  super.preMoveShape(context);
  // ... check some condition ....
  if(....)   {
    ((MoveShapeContext)context).setX(context.getX() - context.getDeltaX());
    ((MoveShapeContext)context).setDeltaX(0);
  }
}

Of course, it does not feel right to cast the interface. But I don't see other way (apart from trigger another move... which I like less).

[Updated on: Tue, 18 October 2011 20:02]

Report message to a moderator

Re: Restricting move [message #740726 is a reply to message #740702]

Tue, 18 October 2011 20:43

Joerg Reichert

Messages: 80
Registered: July 2009
Location: Leipzig

Member

Hi Hernan,

What about overriding the canMoveShape(IMoveShapeContext context) method of the super class? As you can see in the super class the preMoveShape(context) method is executed in the moveShape method so what ever you do in preMoveShape it will not prevent executing moveShape. canMoveShape will do.

Joerg

--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com

Report message to a moderator

Re: Restricting move [message #740747 is a reply to message #740726]

Tue, 18 October 2011 21:16

Hernan Gonzalez

Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina

Senior Member

But I don't want to prevent the move, I just want to restrict it, i.e. to ignore one of the x-y coordinates of the translation.

Report message to a moderator

Re: Restricting move [message #740765 is a reply to message #740747]

Tue, 18 October 2011 21:46

Joerg Reichert

Messages: 80
Registered: July 2009
Location: Leipzig

Member

Then I think your way to cast to MoveShapeContext is the only way to go.

--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com

Report message to a moderator

Re: Restricting move [message #741159 is a reply to message #740765]

Wed, 19 October 2011 08:32

Michael Wenz

Messages: 1914
Registered: July 2009
Location: Walldorf, Germany

Senior Member

That's correct. Do you think we should add the setters to the interface as
well?

Michael

Report message to a moderator

Re: Restricting move [message #741483 is a reply to message #741159]

Wed, 19 October 2011 15:19

Hernan Gonzalez

Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina

Senior Member

Michael Wenz wrote on Wed, 19 October 2011 05:32

That's correct. Do you think we should add the setters to the interface as
well?

Michael

I'm not sure, but I'd say yes.

On the yes side, I feel that this is quite reasonable thing to do in a "preMoveShape()", and this should be allowed - by contract.

On the may-be-not side: Is is reasonable (and already done in other case) to allow a feature method to modify the "context" ? I guess that the 'inmutable by contract' context is implicitly assumed afterwards (if the programmer modifies the context after the premove() method horrible things could happen). Another option is that the premove method could return an "effective delta".

Another problem with this approach is that a this point (preMoveShape calling) we may be a little late to apply a "movement correction": the drag preview didn't reflect it, and the canMove() was evaluated with the 'uncorrected' final position - all this is slightly incorrect, perhaps the user can live with it (I can), but this is not totally clean.

Report message to a moderator

Re: Restricting move [message #742257 is a reply to message #741483]

Thu, 20 October 2011 10:22

Michael Wenz

Messages: 1914
Registered: July 2009
Location: Walldorf, Germany

Senior Member

A counter-argument to the may-be-not side: by doing the cast the change can
be done anyway, so the context is not really immutable. Of course you need
to know what you're doing when you change the context, but you can achieve
quite nice effects (see the Chess example in Git I currently work on).

And also in move (or preMove maybe) you will need to do a feasibility check
because - as you said - canMove did not really check the final thing...

Michael

Report message to a moderator

Previous Topic:	Some small issues with Copy/Paste
Next Topic:	Force model save

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sun Mar 29 16:22:18 GMT 2020

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter