Re: -draggedImageLocation giving incorrect results?

[Richard Frith-Macdonald]

On 26 Apr 2007, at 14:26, Fred Kiefer wrote:

> Michael Gardner wrote:
> > I've got some code in an NSImageView subclass that looks like this:
> >
> > -(void) mouseDown: (NSEvent*)event
> > {
> >        ...
> >        [self dragImage: [self image] at: NSZeroPoint offset:
> > NSZeroSize event: event pasteboard: pboard source: self slideBack:
> > YES];
> >        ...
> > }
> >
> > and in the dragging destination, I position the dropped object at
> > [sender draggedImageLocation]. This worked in the latest release
> > version of GNUstep, but in trunk the value that I get from
> > -draggedImageLocation is offset by 1 pixel horizontally and 9 pixels
> > vertically from where it should be. I believe those dimensions are
> > exactly the width and height of the decorations on the left and  
> > bottom
> > edges of the enclosing window, respectively.
>
> I am not sure here, but to me it looks like the problem stems from the
> fact that your code relies on NSZeroPoint being the origin of the
> window. But when calling this method on the view the handed in point
> will first be translated to window coordinates which may take the  
> window
> border into account, depending on whether GNUstep is handling it or  
> not.
> You could easily work around this by calling the same method on  
> _window
> instead of self.

It's hard to tell without seeing the code for positioning the propped  
object, but perhaps this problem hinges on what is meant by 'position  
the propped object at'

The coordinates returned by the -draggedImageLocation method are the  
coordinates of the bottom left corner of the image in the base  
coordinate system of the window receiving the drag.  That means you  
need to do 'dropPoint = [dropView convertPoint: imageLocation  
fromView: nil];' to convert the point to the coordinate system of  
dropView in order to position the object in dropView.

Now, if dropView is the content view of a window, it can happen that  
the base coordinate system of the window is the same as the  
coordinate system of dropView, so code which is missing the proper  
conversion might have worked before but not work since the coordinate  
conversion code was fixed in gui.  So that seems a likely explanation  
for the problem and would be solved by fixing the bug in the app (ie  
calling -convertPoint:fromView: to get the correct coordinates).

 On the other hand, if the code *is* doing the coordinate  
conversion, and is still going wrong, then there is probably a bug in  
the gui or backend library being used, and we need to investigate that.