Faulty coordinates when using translateToAbsolute & scrolling [message #237253] |
Wed, 22 July 2009 17:43 |
Eclipse User |
|
|
|
Originally posted by: nbe.informatik.uni-kiel.de
Hi all!
I've got an annoying problem I hope you can help me with.
I'm currently trying to develope a highlight effect on an existing
editor where i draw a red rectangle over some existing figure.
It basically works like this:
public void execute() {
// search a layer we can draw on
RootEditPart rootEP = objectToHighlight.getRoot();
if(rootEP instanceof RenderedDiagramRootEditPart){
IFigure layer = ((RenderedDiagramRootEditPart)
rootEP).getLayer(RenderedDiagramRootEditPart.FEEDBACK_LAYER) ;
// get Figure to the EditPart
IFigure selectedFigure = objectToHighlight.getFigure();
// get same bounds as the selected figure ...
Rectangle bounds = selectedFigure.getBounds().getCopy();
// ... but in absolute coordinates
selectedFigure.translateToAbsolute(bounds);
// set the bounds of the Figure that will do the highlighting
highlightFigure.setBounds(bounds);
// add the new highlight figure to the layer
layer.add(highlightFigure);
// schedule a repaint of the feedback layer
layer.invalidate();
}
It works generally well, however, if I scroll or zoom in the main window
the calculated coordinates become wrong. The highlightFigure gets
painted with an offset, e.g. if i scrolled 20 pixels to the right, the
highlightFigure is 20 pixels left to the objectToHighlight where it
should be.
Before translateToAbsolute the coordinates are plausible...
This also seems not to be related to my choice of paint layer, tried a
couple of others with same behaviour.
Any ideas? Help would be greatly appreciated!
Cheers, Nils
|
|
|
|
|
|
Re: Faulty coordinates when using translateToAbsolute & scrolling [message #237307 is a reply to message #237295] |
Thu, 23 July 2009 11:41 |
Eclipse User |
|
|
|
Originally posted by: nbe.informatik.uni-kiel.de
Gary schrieb:
> Hi,
> I'm no expert with the behavour of GMF, but when doing some web
> development I noticed that the mouse position didn't take into account
> the scroll amount!
> So when positioning something (absolute position) according to the
> co-ordinates determained by the mouse, the position was incorrect.
>
> Your issue seams to be producing the same problem, so maby it requires
> the same solution???
> That solution was to get hold of the amount the user has scrolled and
> minus that from the position.
>
> Hope this was useful,
> Gary
>
Thanks for your input. I had the same idea and compared all the parent
objects when scrolled and when not. However i can't find any difference
at all. Maybe anyone knows where to grab to scrolling values?
Peter, i tried your workaround, but this gives me another (if
scroll-independent) offset upwards and to the left for all items except
for the top level node... Any ideas?
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03243 seconds