gnustep-dev
[Top][All Lists]
Advanced

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

Re: -draggedImageLocation giving incorrect results?


From: Michael Gardner
Subject: Re: -draggedImageLocation giving incorrect results?
Date: Sat, 28 Apr 2007 18:13:32 -0500

Thanks for the response. I'm not using NSZeroPoint as the origin of
the window, but rather of the subview itself. The intended result is
that the drag image be displayed starting exactly where the subview
currently is. The above code does this, but as I mentioned, [sender
draggedImageLocation] then returns the wrong result.

Sending the dragImage: message to [self window] instead causes [sender
draggedImageLocation] to give the correct result, but instead the
image is displayed in the wrong place during dragging-- it's offset by
the same amount as in the previous case, but in the opposite
direction.

It seems to me that there is a mismatch between the code that
determines where to display the dragging image, and the code that
returns [sender draggedImageLocation]-- one of them is taking the
window decorations into account, while the other is not.

As I mentioned, this only happens in trunk; the latest release is
fine. But the trunk builds have been doing this for a while now, and
I'd like to make sure that if this is a bug, it doesn't get into a
release.

-Michael

On 4/26/07, Fred Kiefer <address@hidden> 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.

Cheers,
Fred





reply via email to

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