Re: Stop dragging my <NSWindow> around
Re: Stop dragging my <NSWindow> around
- Subject: Re: Stop dragging my <NSWindow> around
- From: Dietmar Planitzer <email@hidden>
- Date: Thu, 3 Feb 2005 21:16:51 +0100
On Feb 3, 2005, at 2:32 PM, 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.
So in my event loop I am filtering out mouseDragged events. For every
other type of event I call [super sendEvent:], but I do not call super
for mouseDragged. On a mouseDragged event in my event loop, no code
runs at all (not even the 'default' section of the switch).
My aim is to prevent the window from being dragged automatically by
the OS / Window Server / Cocoa... I want complete control of where the
window is being moved. Otherwise, you get the OS doing its thing, then
your code doing your thing (or vice versa), resulting in juddery
movement during each stage of a drag. So at the moment I'm trying to
prevent my window from being moved automatically during a drag. Once I
know the window is stationary I can go about adding code to move it
appropriately, in the knowledge that nothing else is interfering.
However, despite trying to block all attempts by Cocoa to move my
window around when I drag on the titlebar, it's still moving happily
around the screen (as per a normal panel when you drag the titlebar).
It's definitely not my event loop doing it, and my notification
methods are all blank (and not calling [super makeHimGoMad] etc.), so
does anyone know what it is that's causing the window to move around?
I'm guessing the window server, but if this is the case, how do I go
about tell it to leave off my window?
Please tell me if I'm barking up the wrong tree!
OS X supports two different styles of window dragging: synchronous and
asynchronous.
Synchronous window dragging means that the application itself waits for
a mouse down event into the window title bar and starts a mouse
tracking loop when it sees such an event. The tracking loop then moves
the window as needed. This style of window dragging is the default in
Carbon and still used by many (older) Carbon apps.
Asynchronous window dragging is the default in Cocoa. In this scheme,
the AppKit tells the window server where the drag region of the window
is (the title bar) and the window server itself then traps and handles
mouse downs into the drag region. If such a mouse down occurs then the
window server moves the window around as needed and probably notifies
the AppKit of the new window state after the dragging has completed.
It looks like what you would need is the synchronous window dragging
style. Sadly there is currently no way to tell the NSWindow class that
it should switch from its default async style to a sync dragging style.
There are basically three things that you could do:
1) Use a borderless window and implement your own frame view. That
frame view would be responsible for drawing the window title bar and
window dragging. I guess, you should be able to draw the title bar by
using some HITheme drawing APIs from the Carbon framework.
2) Try using a Carbon window in place of an NSWindow. This may be
completely impractical if you want to use NSViews / NSControls.
3) File an enhancement request with Apple's Radar, asking Apple for the
addition of a NSWindow delegate method which could look like this one:
-(NSPoint)window: (NSWindow *)window willMoveToTopLeftPoint:
(NSPoint)point
The NSWindow class would check whether its delegate implements the
above method, and if it does, then it would switch from async dragging
mode to sync dragging mode. The AppKit would then repeatedly call the
delegate method while the user is moving the window around with the new
window top-left position in screen coordinates as its second argument.
The delegate method could then either just return the passed in point
or another point. This would make it very easy to pin the window to a
certain screen location.
Its really very unfortunate that as Cocoa developers we have currently
to go through such great lengths (implement our own frame view) just to
be able to snap a window to a screen edge or the border of another
window...
Regards,
Dietmar Planitzer
_______________________________________________
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