Re: Stop dragging my <NSWindow> around
Re: Stop dragging my <NSWindow> around
- Subject: Re: Stop dragging my <NSWindow> around
- From: Ken Tabb <email@hidden>
- Date: Thu, 3 Feb 2005 17:56:07 +0000
On 3 Feb 2005, at 3:19 pm, glenn andreas wrote:
On Feb 3, 2005, at 7:32 AM, Ken Tabb wrote:
... to hijack a Stevie Nicks song title...
Hi folks,
I'm still trying to implement window snap-to-edge functionality with
my panels (further to my "mouseDown/Up on window's titlebar?" post).
Although the window doesn't get mouseDown / mouseUp called by default
when you click / release the titlebar, overriding your window's
-sendEvent: allows you to catch all mouseDowns / mouseUps.
Why not try overriding the various setFrame calls instead, to lock
them to the edge as appropriate? You'd probably want to add "if
dragging the window" logic (say, by checking if the mouse was down).
After looking at the documentation, you might even be able to use
"windowWillResize" delegate message since that is called for manual
resizing as well as "through one of the setFrame... methods other than
setFrame:display:" (and then call setFrame:display: directly from
there your self to grid it)
It might be worth a try...
Cheers for the ideas Glenn,
the weird thing is I've already overridden setFrame:display:animate,
setFrame:display and setFrameOrigin: in my window, to the extent that
it places the window's origin at (150, 150) - for testing purposes of
course so that I know it's not moving it. And still the blasted little
thing moves haplessly across the screen. So when you drag the titlebar,
it initially (in the first stage of the drag) places the window at
(150, 150) as per my code... and then in the rest of the drag it moves
the window around, with it miles away from your cursor position (as the
cursor didn't get moved to (150,150).
I've also implemented the notification methods, but they only get
called after The OS X Phantom has moved the window, so you get a judder
where first The OS X Phantom moves my window, then I move it back
again, per stage of the drag.
I wonder if this is the same thing that causes an NSWindow's -frame
method to be out-of-date during a drag (it returns the frame that was
correct at the start of the drag, not the current one during a drag,
unless you're explicitly calling -setFrame etc. during the drag). i.e.
I wonder if something (Quartz window server) is moving the window
without the NSWindow realising it's being moved. Notifications pick up
on it, but I wonder if something further upstream from my code is in
the driving seat with respect to the window's position; the fact that
something seems to be moving my window without calling -setFrame /
-setFrameOrigin etc. is worrying... I suddenly don't feel in control of
this bus any longer.
Alternatively, maybe something else has also registered for
windowDidMove etc. notifications of my window... my NSApp maybe, or
something more Core Graphics-y. Is there any way to prevent all objects
that have registered for a certain notification from getting those
notifications? (i.e. so that they can't move my window)? I appreciate
this sounds like the cry of a desperate man, but I'm a desperate man,
crying 8^)
At this point in time I would very much like to meet the Quartz window
server down a blind alley some night...
Most perplexing...
Ken
- - - - - - - - - -
Dr. Ken Tabb
Mac & UNIX Developer - Health & Human Sciences
Machine Vision & Neural Network researcher - School of Computer Science
University of Hertfordshire, UK
http://www.health.herts.ac.uk/ken/
Certified non-Microsoft Solution Provider
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden