[NSTableView] option + click change of behavior between Tiger and Leopard

  • I'm seeing a difference between Leopard and Tiger regarding some code
    I'm using to handle an option-click in a NSTableView.

    Basically, I have a subclass of NSTableView that does this:

    - (void) mouseDown:(NSEvent *) inEvent
    {
    BOOL tOptionClick=NO;

    if ([inEvent clickCount]==1 && ([inEvent modifierFlags] &
    (NSControlKeyMask|NSAlternateKeyMask))==NSAlternateKeyMask)
    {
      tOptionClick=YES;

      inEvent=[NSEvent mouseEventWithType:[inEvent type]
                                     location:[inEvent locationInWindow]
                                 modifierFlags:0
                                     timestamp:[inEvent timestamp]
                                 windowNumber:[inEvent windowNumber]
            context:[inEvent context]
            eventNumber:[inEvent eventNumber]
                                    clickCount:[inEvent clickCount]
                                     pressure:[inEvent pressure]];

    }

    [super mouseDown:inEvent];

    if (tOptionClick==YES)
    {
      if ([self delegate]!=nil)
      {
      [[self delegate] tableViewDidOptionClick:self];
      }
    }
    }

    On Tiger, it works as I would like it to work:

      When I option-click a row, it selects the row and then call
    tableViewDidOptionClick. The clicked cell does not enter edit mode.

    On Leopard, it does not work as I would like to work:

      When I option-click a row, it selects the row and then call
    tableViewDidOptionClick. BUT the clicked cell enters edit mode.

    I could probably workaround this by adding an ivar to the subclass of
    NSTableView so that - (BOOL)tableView:(NSTableView *)tableView
    shouldEditTableColumn:(NSTableColumn *)tableColumn row:(int)row returns
    NO when [super mouseDown:inEvent] is called.

    But would there be a better way to proceed?
  • On Nov 20, 2007, at 7:48 AM, Stephane Sudre wrote:

    > I'm seeing a difference between Leopard and Tiger regarding some
    > code I'm using to handle an option-click in a NSTableView.
    >
    > Basically, I have a subclass of NSTableView that does this:
    >
    > - (void) mouseDown:(NSEvent *) inEvent
    > {
    > BOOL tOptionClick=NO;
    >
    > if ([inEvent clickCount]==1 && ([inEvent modifierFlags] &
    > (NSControlKeyMask|NSAlternateKeyMask))==NSAlternateKeyMask)
    > {
    > tOptionClick=YES;
    >
    > inEvent=[NSEvent mouseEventWithType:[inEvent type]
    > location:[inEvent locationInWindow]
    > modifierFlags:0
    > timestamp:[inEvent timestamp]
    > windowNumber:[inEvent windowNumber]
    > context:[inEvent context]
    > eventNumber:[inEvent eventNumber]
    > clickCount:[inEvent clickCount]
    > pressure:[inEvent pressure]];
    >
    > }
    >
    > [super mouseDown:inEvent];
    >
    > if (tOptionClick==YES)
    > {
    > if ([self delegate]!=nil)
    > {
    > [[self delegate] tableViewDidOptionClick:self];
    > }
    > }
    > }
    >
    > On Tiger, it works as I would like it to work:
    >
    > When I option-click a row, it selects the row and then call
    > tableViewDidOptionClick. The clicked cell does not enter edit mode.
    >
    > On Leopard, it does not work as I would like to work:
    >
    > When I option-click a row, it selects the row and then call
    > tableViewDidOptionClick. BUT the clicked cell enters edit mode.
    >
    >
    > I could probably workaround this by adding an ivar to the subclass
    > of NSTableView so that - (BOOL)tableView:(NSTableView *)tableView
    > shouldEditTableColumn:(NSTableColumn *)tableColumn row:(int)row
    > returns NO when [super mouseDown:inEvent] is called.

    That would be a good work around; basically, you are preventing
    NSTableView from knowing that the option key was held down...so it
    thinks it should start editing.
    >
    >
    > But would there be a better way to proceed?

    If you are linking against leopard you could implement
    "hitTestForEvent:" in the NSCell subclass that is used, however, you
    will probably have the same problem of requiring an extra ivar to
    maintain state indicating it shouldn't return editable text.

    corbin
previous month november 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    
Go to today