Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Graphiti » Restricting move
Restricting move [message #740702] Tue, 18 October 2011 20:01 Go to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
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 Go to previous messageGo to next message
Joerg Reichert is currently offline Joerg ReichertFriend
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
Re: Restricting move [message #740747 is a reply to message #740726] Tue, 18 October 2011 21:16 Go to previous messageGo to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
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.
Re: Restricting move [message #740765 is a reply to message #740747] Tue, 18 October 2011 21:46 Go to previous messageGo to next message
Joerg Reichert is currently offline Joerg ReichertFriend
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
Re: Restricting move [message #741159 is a reply to message #740765] Wed, 19 October 2011 08:32 Go to previous messageGo to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1931
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
Re: Restricting move [message #741483 is a reply to message #741159] Wed, 19 October 2011 15:19 Go to previous messageGo to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
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.
Re: Restricting move [message #742257 is a reply to message #741483] Thu, 20 October 2011 10:22 Go to previous message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1931
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
Previous Topic:Some small issues with Copy/Paste
Next Topic:Force model save
Goto Forum:
  


Current Time: Fri Apr 19 00:46:53 GMT 2024

Powered by FUDForum. Page generated in 0.02867 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top