Restricting NSWindow Movement

  • Is there a way to restrict the movement of an NSWindow to a frame of another window (that may underly it) or to some other fixed rectangular sub-area on the screen?

    Searching the web there was a CocoaBuilder thread 12 years ago that indicates that it was unknown how to do this then, implying that optimization in the Window Manager was an issue, but holding out the possibility that a layer below Cocoa might allow it.

    The windowWillMove: delegate method does not allow vetoing the move. In contrast to the windowWillResize:toSize: delegate method that does allow resizing to be vetoed.

    If your answer to this question would be to ask me why I should want to do such a thing, please consider that that is not an answer.

    Thanks,

    Tom Wetmore
  • The doc for [NSWindow isMovable] says you can disable it and implement your own mouseDown: in an NSWindow subclass. I think there used to be an example mouseDown: implementation in the code but I can't find it.

    On May 6, 2013, at 2:17 PM, Thomas Wetmore wrote:

    > Is there a way to restrict the movement of an NSWindow to a frame of another window (that may underly it) or to some other fixed rectangular sub-area on the screen?
    >
    > Searching the web there was a CocoaBuilder thread 12 years ago that indicates that it was unknown how to do this then, implying that optimization in the Window Manager was an issue, but holding out the possibility that a layer below Cocoa might allow it.
    >
    > The windowWillMove: delegate method does not allow vetoing the move. In contrast to the windowWillResize:toSize: delegate method that does allow resizing to be vetoed.
    >
    > If your answer to this question would be to ask me why I should want to do such a thing, please consider that that is not an answer.
    >
    > Thanks,
    >
    > Tom Wetmore
  • Hi Tom,

    I've been dealing with constraining window motion a bit lately. Unfortunately, Cocoa does not provide an easy way to do this (like Carbon did). You essentially have to handle the mouse events yourself, in an NSWindow subclass.

    So, subclass NSWindow, and implement the following (I included some of the code I used):

    - (void)
    mouseDown: (NSEvent*) inEvent
    {
        CGRect b = self.frame;
        b = [self convertRectFromScreen: b];
        CGPoint p = inEvent.locationInWindow;

        mDragOffset.x = b.origin.x - p.x;
        mDragOffset.y = b.origin.y - p.y;
    }

    - (void)
    mouseDragged: (NSEvent*) inEvent;
    {
        CGRect b = self.frame;
        b = [self convertRectFromScreen: b];

        CGPoint p = inEvent.locationInWindow;
        b.origin.x = p.x + mDragOffset.x;
        b.origin.y = p.y + mDragOffset.y;

        b = [self convertRectToScreen: b];
        [self setFrame: b display: true];

    }

    - (void)
    mouseUp: (NSEvent*) inEvent;
    {
        //  Nothing really needs be done here
    }

    On May 6, 2013, at 14:17 , Thomas Wetmore <ttw4...> wrote:

    > Is there a way to restrict the movement of an NSWindow to a frame of another window (that may underly it) or to some other fixed rectangular sub-area on the screen?
    >
    > Searching the web there was a CocoaBuilder thread 12 years ago that indicates that it was unknown how to do this then, implying that optimization in the Window Manager was an issue, but holding out the possibility that a layer below Cocoa might allow it.
    >
    > The windowWillMove: delegate method does not allow vetoing the move. In contrast to the windowWillResize:toSize: delegate method that does allow resizing to be vetoed.
    >
    > If your answer to this question would be to ask me why I should want to do such a thing, please consider that that is not an answer.
    >
    > Thanks,
    >
    > Tom Wetmore

    --
    Rick
  • On May 6, 2013, at 16:17:49, Thomas Wetmore <ttw4...> wrote:

    > Is there a way to restrict the movement of an NSWindow to a frame of another window (that may underly it) or to some other fixed rectangular sub-area on the screen?
    >
    > Searching the web there was a CocoaBuilder thread 12 years ago that indicates that it was unknown how to do this then, implying that optimization in the Window Manager was an issue, but holding out the possibility that a layer below Cocoa might allow it.
    >
    > The windowWillMove: delegate method does not allow vetoing the move. In contrast to the windowWillResize:toSize: delegate method that does allow resizing to be vetoed.
    >
    > If your answer to this question would be to ask me why I should want to do such a thing, please consider that that is not an answer.

    I had a thread about snapping windows as they move or resize recently, so check the archives. Apple offers no easy way to do this. I had to override sendEvent:, catch NSLeftMouseDown, check to see if the click was in the titlebar, if so, set some instance variables that says we're dragging the window. Also catch NSLeftMouseDragged (if we know we're dragging the window) and calculate the new rect based on the mouse movement and the windows I wanted to snap to. Finally catch NSLeftMouseUp to reset my instance variables.

    --
    Steve Mills
    Drummer, Mac geek
  • Oh yeah, add this to -awakeFromNib, or some other appropriate place:

        self.movable = false;

    Also note that in doing this, you'll lose the ability for your windows to be moved even if your app is not responding.

    On May 6, 2013, at 14:17 , Thomas Wetmore <ttw4...> wrote:

    > Is there a way to restrict the movement of an NSWindow to a frame of another window (that may underly it) or to some other fixed rectangular sub-area on the screen?
    >
    > Searching the web there was a CocoaBuilder thread 12 years ago that indicates that it was unknown how to do this then, implying that optimization in the Window Manager was an issue, but holding out the possibility that a layer below Cocoa might allow it.
    >
    > The windowWillMove: delegate method does not allow vetoing the move. In contrast to the windowWillResize:toSize: delegate method that does allow resizing to be vetoed.
    >
    > If your answer to this question would be to ask me why I should want to do such a thing, please consider that that is not an answer.
    >
    > Thanks,
    >
    > Tom Wetmore

    --
    Rick
previous month may 2013 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Go to today