How to track a lost mouseDown

  • Folks;

    I have custom view that is not receiving a mouseDown.
    How do most efficiently track what is happening to the event?

    The mainWindow's contentView has a single tabView with 3 tabViewItems.
    The visible tabViewItem consists of a splitView with my custom view
    as one side of this split view.

    My customView's - resetCursorRects gets called and the cursor changes
    correctly when mouse moves thru the rect.

    However when I then mouseDown (inside the changed cursorRect!) - nothing

    I'm just stumped on how to debug this...
    My gut tells me that there is something in the Responder chain that I
    am understanding but what that might be - I don't know.

    Any pointers?
    Thank-you
    Steve
  • > I have custom view that is not receiving a mouseDown.
    > How do most efficiently track what is happening to the event?

      With respect, you're asking the wrong question. You need to ask,
    "How do I receive -mouseDown: in my custom view?"

    > My customView's - resetCursorRects gets called and the cursor changes
    > correctly when mouse moves thru the rect.
    > However when I then mouseDown (inside the changed cursorRect!) - nothing

      What makes you think a cursor rect has anything to do with
    mouse-down events? It's a *cursor* rect. ;-)

      Search the docs for "tracking rect". You need to implement
    -addTrackingRect:owner:userData:assumeInside: in all the right places
    to add, keep track of, and remove tracking rects when your view's
    frame changes or it's added to / removed from a
    window/superview/whatever your situation calls for.

    --
    I.S.
  • On 8/27/07, I. Savant <idiotsavant2005...> wrote:
    >> I have custom view that is not receiving a mouseDown.
    >> How do most efficiently track what is happening to the event?
    >
    > With respect, you're asking the wrong question. You need to ask,
    > "How do I receive -mouseDown: in my custom view?"

      I'm an idiot. :-D  I kept reading that as the -mouseEntered:,
    -mouseExited:, and -mouseMoved: methods ... even though I *wrote*
    -mouseDown: myself ... (sigh)

      In short, I have steered you wrong.

    > What makes you think a cursor rect has anything to do with
    > mouse-down events? It's a *cursor* rect. ;-)

      *THIS* is still accurate, though. So is my original statement about
    your question. Tracking where some random mouse event isn't what you
    should be interested in ... working out why the event isn't making it
    to your custom view is.

      How have you verified your custom view's -mouseDown: method is not
    being called? NSLog()? A breakpoint? Are you returning YES for
    -acceptsFirstResponder: in your custom view?

    --
    I.S.
  • On 27.08.2007, at 19:53, Steve Cronin wrote:
    > My customView's - resetCursorRects gets called and the cursor
    > changes correctly when mouse moves thru the rect.

      So, I guess the view is where you think it should be, good.

    > However when I then mouseDown (inside the changed cursorRect!) -
    > nothing

      Have you tried setting a breakpoint in your mouseDown method and
    running it in the debugger to see whether it's called, or added an
    NSLog() call at the start? Maybe it *is* called but your code just
    doesn't do what you think it should? If it isn't called, have you
    checked your mouseDown method's name, parameters and return value for
    correctness? I.e. are they exactly the same as in the declaration in
    NSResponder or NSView or wherever they're first declared?

      Can you post your mouseDown method? Can you post the header for
    your class? (In particular, what have you chosen as the base class,
    and what other methods are you overriding?)

      Is your view frontmost?

      It's always a good idea to run your code in the debugger and add
    NSLog() calls to see where it is failing exactly, (if the debugger
    doesn't trigger, always try an NSLog() or NSBeep() -- Sometimes the
    debugger just got confused or you're accidentally running a release
    build). And when posting here, posting code is always helpful.

      To find out where an event is going, you could override sendEvent:
    in NSApplication and NSWindow (using method swizzling), and add a
    mouseDown method to NSResponder, to detect some places where an event
    may go, but I'm not sure there's a way to get informed of events that
    get dispatched to other views.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • Uli;

    Thanks for responding!

    Yes I noted the cursorRect behavior to support the notion that the
    view is instantiated and behaving somewhat as expected.

    Yes I have set a breakpoint and an NSLog statement.  Neither ever fires.
    Yes it is frontmost view.

    Here's the header:
    @interface MySpecialView : NSView {
    }
    @end

    Here's the implementation:
    #import "MySpecialView.h"

    @implementation MySpecialView

    - (void)awakeFromNib
    {
    NSLog(@"superV = %@",[self superview]);
    NSLog(@"supersuperV = %@",[[self superview] superview]);
    }

    - (BOOL)acceptsFirstResponder
    {
    return YES;
    }

    - (void)resetCursorRects
    {
    [super resetCursorRects];
    NSRect resizeSizeRect = NSMakeRect(NSWidth([self frame]) - 23, 0,
    23, 23);
    [self addCursorRect:resizeSizeRect cursor:[NSCursor
    pointingHandCursor]];
    }

    - (void)mouseDown:(NSEvent *)event
    {
    NSLog(@"mouseDown Received");
    }

    That's it.  I never see the log entry for mouseDown no matter where
    in the view I click!

    If I put other IB widgets in the view (buttons, tableViews, etc) they
    all receive and handle clicks correctly.

    I'm definitely running in debug mode.
    I don't understand your final comments about adding to NSResponder....

    Thanks Again for your time!
    Steve

    On Aug 27, 2007, at 1:23 PM, Uli Kusterer wrote:

    > On 27.08.2007, at 19:53, Steve Cronin wrote:
    >> My customView's - resetCursorRects gets called and the cursor
    >> changes correctly when mouse moves thru the rect.
    >
    > So, I guess the view is where you think it should be, good.
    >
    >> However when I then mouseDown (inside the changed cursorRect!) -
    >> nothing
    >
    > Have you tried setting a breakpoint in your mouseDown method and
    > running it in the debugger to see whether it's called, or added an
    > NSLog() call at the start? Maybe it *is* called but your code just
    > doesn't do what you think it should? If it isn't called, have you
    > checked your mouseDown method's name, parameters and return value
    > for correctness? I.e. are they exactly the same as in the
    > declaration in NSResponder or NSView or wherever they're first
    > declared?
    >
    > Can you post your mouseDown method? Can you post the header for
    > your class? (In particular, what have you chosen as the base class,
    > and what other methods are you overriding?)
    >
    > Is your view frontmost?
    >
    > It's always a good idea to run your code in the debugger and add
    > NSLog() calls to see where it is failing exactly, (if the debugger
    > doesn't trigger, always try an NSLog() or NSBeep() -- Sometimes the
    > debugger just got confused or you're accidentally running a release
    > build). And when posting here, posting code is always helpful.
    >
    > To find out where an event is going, you could override sendEvent:
    > in NSApplication and NSWindow (using method swizzling), and add a
    > mouseDown method to NSResponder, to detect some places where an
    > event may go, but I'm not sure there's a way to get informed of
    > events that get dispatched to other views.
    >
    > Cheers,
    > -- M. Uli Kusterer
    > http://www.zathras.de
    >
    >
    >
  • On 27 Aug 2007, at 20:24, Steve Cronin wrote:

    > Yes I noted the cursorRect behavior to support the notion that the
    > view is instantiated and behaving somewhat as expected.
    >
    > Yes I have set a breakpoint and an NSLog statement.  Neither ever
    > fires.
    > Yes it is frontmost view.

    Is this view overlapped by something else?  I'm not sure that
    overlapping views necessarily work properly in Tiger... it's quite
    possible that a view earlier in the child views list of a parent view
    might get a click even if a later view looks like it's "on top".

    What are the superviews of this view?  Did you implement a method
    called -hitTest: on your view?  Or on any of its superviews?  (If so,
    does it do what the framework expects?)

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
previous month august 2007 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