knowing if a titlebar click is actually a resize click

  • How can I tell in my sendEvent override that a click is supposed to resize the window from the top and not drag the window?

    --
    Steve Mills
    office: 952-818-3871
    home: 952-401-6255
    cell: 612-803-6157
  • On Jun 12, 2013, at 10:48 AM, Steve Mills wrote:

    > How can I tell in my sendEvent override that a click is supposed to resize the window from the top and not drag the window?

    I assume you're having to display the resize cursor yourself since the window is marked as non-resizable? Naturally, being within that tracking rect would determine if it's a resize click.

    --
    Seth Willits
  • On Jun 12, 2013, at 14:20:51, Seth Willits <slists...> wrote:

    > On Jun 12, 2013, at 10:48 AM, Steve Mills wrote:
    >
    >> How can I tell in my sendEvent override that a click is supposed to resize the window from the top and not drag the window?
    >
    > I assume you're having to display the resize cursor yourself since the window is marked as non-resizable? Naturally, being within that tracking rect would determine if it's a resize click.

    No, just the opposite. I'm handling moving so we can snap to other windows, so our move code is running because the click is in the titlebar, even when Cocoa has already changed the cursor to a resize cursor. Are those tracking rects exposed in a public API? NSView has a trackingRects method, but the window doesn't.

    --
    Steve Mills
    office: 952-818-3871
    home: 952-401-6255
    cell: 612-803-6157
  • On Jun 12, 2013, at 2:45 PM, Steve Mills wrote:

    > On Jun 12, 2013, at 14:20:51, Seth Willits <slists...> wrote:
    >
    >> On Jun 12, 2013, at 10:48 AM, Steve Mills wrote:
    >>
    >>> How can I tell in my sendEvent override that a click is supposed to resize the window from the top and not drag the window?
    >>
    >> I assume you're having to display the resize cursor yourself since the window is marked as non-resizable? Naturally, being within that tracking rect would determine if it's a resize click.
    >
    > No, just the opposite. I'm handling moving so we can snap to other windows, so our move code is running because the click is in the titlebar, even when Cocoa has already changed the cursor to a resize cursor. Are those tracking rects exposed in a public API? NSView has a trackingRects method, but the window doesn't.

    Does NSWindowWillStartLiveResizeNotification (or -[NSWindowDelegate windowWillStartLiveResize:]) happen in time for you to cancel your drag stuff?

    Regards,
    Ken
  • On Jun 12, 2013, at 16:21:06, Ken Thomases <ken...>
    wrote:

    > Does NSWindowWillStartLiveResizeNotification (or -[NSWindowDelegate windowWillStartLiveResize:]) happen in time for you to cancel your drag stuff?

    Nope. The default sendEvent appears to stay in the mouseDown event handler (NSTitledFrame mouseDown) until the mouse has moved 3 or 4 pixels, then it fires off the NSWindowWillStartLiveResizeNotification.

    --
    Steve Mills
    office: 952-818-3871
    home: 952-401-6255
    cell: 612-803-6157
  • On Jun 12, 2013, at 12:45 PM, Steve Mills wrote:

    >> On Jun 12, 2013, at 10:48 AM, Steve Mills wrote:
    >>
    >>> How can I tell in my sendEvent override that a click is supposed to resize the window from the top and not drag the window?
    >>
    >> I assume you're having to display the resize cursor yourself since the window is marked as non-resizable? Naturally, being within that tracking rect would determine if it's a resize click.
    >
    > No, just the opposite. I'm handling moving so we can snap to other windows, so our move code is running because the click is in the titlebar, even when Cocoa has already changed the cursor to a resize cursor. Are those tracking rects exposed in a public API? NSView has a trackingRects method, but the window doesn't.

    Hmm. I would have though a non-movable window couldn't be resized and thus wouldn't show the resize cursor.

    I don't know that the OS uses standard tracking rects — I was thinking you'd be providing your own according to the above. Since that's not the case, you'll just have to do the simple checking to see if the click is within the top edge of the window. The only potential disconnect is that you may assume the top X points are click-to-resize when it's actually Y points. That's not likely to change change much if at all over the years, so doing the hit test yourself is pretty safe.

    The only other potential solution I see is to check to see if the cursor is a resize cursor. I don't know if that cursor change is available at the app level so that might not be doable. (In addition, I think you'll have issues if the window is in the background since the cursor isn't shown but the window should still be resizable and I think you still have to control the resizing?)

    --
    Seth Willits
  • On Jun 12, 2013, at 4:48 PM, Steve Mills wrote:

    > On Jun 12, 2013, at 16:21:06, Ken Thomases <ken...>
    > wrote:
    >
    >> Does NSWindowWillStartLiveResizeNotification (or -[NSWindowDelegate windowWillStartLiveResize:]) happen in time for you to cancel your drag stuff?
    >
    > Nope. The default sendEvent appears to stay in the mouseDown event handler (NSTitledFrame mouseDown) until the mouse has moved 3 or 4 pixels, then it fires off the NSWindowWillStartLiveResizeNotification.

    I'm not sure I understand.  It's running an internal event loop?  If that's the case, then you definitely get the NSWindowWillStartLiveResizeNotification before seeing an NSLeftMouseDragged.  So, while you would have had to set up for your window moving during the NSLeftMouseDown, you can undo your internal state changes upon seeing the NSWindowWillStartLiveResizeNotification and then subsequently ignore any NSLeftMouseDragged events you see.

    Actually, if you call super before handling mouse events as potential window dragging, then you should know if an NSLeftMouseDragged is a potential drag based on whether or not NSWindowWillStartLiveResizeNotification was posted during the call to super.

    Or am I misunderstanding?

    Regards,
    Ken
previous month june 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
Go to today