OutlineView shouldSelectItem Being Called Twice

  • I've got a view controller set up as the delegate for an outlineView. The view controller implements the -(BOOL)outlineView:(NSOutlineView *)outlineView shouldSelectItem:(id)item delegate method. I show an alert and return NO if the user has not saved some changes or return YES if all is well. The problem is that when I return no the delegate method fires twice. Even when I strip out all of my code and just log the method as shown below it shows two calls. Returnign YES works fine. I thought maybe it's because it was firing once for the original election change and then again to return back to the original selection but logging "item" showed its the same row for both calls.

    -(BOOL)outlineView:(NSOutlineView *)outlineView shouldSelectItem:(id)item
    {
    NSLog(@"firing");
    return NO;
    }

    Is this normal behavior? Thanks for the help.

    -CT
  • On 05/06/2013, at 11:56 AM, Chris Tracewell <chris...> wrote:

    > Is this normal behavior? Thanks for the help.

    Probably. This method should just answer the question, not attempt to interrupt things by showing an alert etc. You'll need to put that functionality elsewhere.

    --Graham
  • Thanks for the reply. This OV is acting as a master for a detail view that must be saved before the selection changes if it's dirty. Is there another method to intercept the OV row click before selection actually changes wherein I can validate and present an NSAlert for save,cancel,discard options if need be?

    -CT

    On Jun 4, 2013, at 7:31 PM, Graham Cox <graham.cox...> wrote:

    >
    > On 05/06/2013, at 11:56 AM, Chris Tracewell <chris...> wrote:
    >
    >> Is this normal behavior? Thanks for the help.
    >
    >
    > Probably. This method should just answer the question, not attempt to interrupt things by showing an alert etc. You'll need to put that functionality elsewhere.
    >
    > --Graham
    >
    >
  • On 06/06/2013, at 5:01 AM, Chris Tracewell <chris...> wrote:

    > Thanks for the reply. This OV is acting as a master for a detail view that must be saved before the selection changes if it's dirty. Is there another method to intercept the OV row click before selection actually changes wherein I can validate and present an NSAlert for save,cancel,discard options if need be?

    From a usability perspective, this doesn't sound like a very friendly design. If I click a row and (by some means) get a barrage of "Save Changes?" alerts I'm going to become pretty wary of exploring your interface.

    Instead, why not just track the dirty state for each 'detail' and save them all in one go at some more appropriate time, such as when the window is dismissed, or when the user clicks a 'Save' button, or just quietly save them to a temporary file... I don't know what is most appropriate for your app but anything that doesn't interrupt the UI 'flow' would most likely be better than the current approach.

    That said, your controller could refuse the selection change if the dirty state is detected, but not to directly present an alert. Instead, it could ask itself to perform a selector after a delay (which can be 0), and knowing that it might get called more than once, be prepared to cancel a previous request before sending a new one so that the alert only shows up once.

    --Graham
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