[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: -draggedImageLocation giving incorrect results?

From: Richard Frith-Macdonald
Subject: Re: -draggedImageLocation giving incorrect results?
Date: Mon, 30 Apr 2007 07:01:22 +0100

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:

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]