Re: NSTableView reloadData question FOLLOWUP
Re: NSTableView reloadData question FOLLOWUP
- Subject: Re: NSTableView reloadData question FOLLOWUP
- From: Bill Cheeseman <email@hidden>
- Date: Wed, 10 Apr 2002 16:39:21 -0400
I solved the problem. It was something totally unexpected, the result of an
unusual confluence of design decisions that I would guess nobody has
previously encountered. I would call it a bug in NSTableView, except that I
haven't explored it deeply enough yet. I'll report it to the bugreporter
later today, unless somebody talks me out of it.
The problem stems from these two facts: (1) Clicking a table view's column
headers or scroll bar does not make the table view (nor the scroller in
which it is embedded) first responder; instead, whatever was first responder
before the click remains first responder afterwards. (2) Yet double-clicking
a table's column headers does invoke the table view's double-click action
method, if you have invoked NSTableView's setDoubleAction: to make your
table respond to double-clicks -- the documentation is clear that this is
intentional. These two facts seem flatly inconsistent to me, and therefore a
bug. If the column headers are considered part of the table for purposes of
invoking a doubleAction, they should be considered part of the table for
purposes of making the table first responder.
Now, as it happens, I apply my table filter by using a combo box, and I
invoke my table addRecord action by setting it as the table's doubleAction.
After choosing a filter from the combo box's pop-up menu or typing the name
of a filter into its text field and pressing Enter, the combo box's action
message is sent and the table is filtered. But the combo box retains first
responder status, as noted above. Then the bug bites me: When I double-click
the table's column headers to add a record, (1) the combo box remains first
responder because clicking a table's column header doesn't make the table
first responder, yet (2) double-clicking the table header does invoke my
table's doubleAction, which attempts to add a new record. Apparently because
the table is not first responder, it's loadData method called in my
addRecord action doesn't load the dataSource array into the table. Worse
yet, my addRecord action tries to leave the newly added record's first cell
selected for immediate editing, but when the addRecord action gets to my
call to editColumn:row:withEvent:select:, I get an error because the row
hasn't been added to the table, and besides, the table isn't first
responder.
The cure is to force the table to become first responder at the beginning of
my doubleAction method, which is the addRecord action: it's in my window
controller, so I call [[self window] makeFirstResponder:[self myTable]]. I
wonder: is this supposed to be standard Cocoa coding practice? -- that you
have to make a control first responder explicitly, instead of relying on
Cocoa to do it for you at appropriate times? I didn't think so in this case.
So now I have two questions:
1. Shouldn't clicking a table's column headers or scroll bars make the table
first responder?
2. Alternatively, shouldn't a table's doubleAction respond only to
double-clicks within the body of the table; that is, on the same part of the
table where a single-click makes the table first responder? -- i.e., not the
column headers or scroll bar?
But option 2 would run into a second bug. I haven't mentioned this yet, but
when the table is empty, it responds only to double-clicks in the column
headers; double-clicks in the body of an empty table do not work. As soon as
there's at least one row visible in the table, double-clicking anywhere in
the empty part of the table's main body does work. This is apparently the
result of Cocoa's inconsistent application of the doubleAction rule that
doubleActions work only on the column headers and on non-editable cells. An
empty table is treated as if it has NO non-editable cells; yet as soon as
you add a single row, the entire empty body of the table is treated as if it
were full of non-editable cells for purposes of the doubleAction. This is
inconsistent.
I spent two solid days tracking all this down, so I feel justified in
subjecting you all to such a lengthy report. If I've overlooked or misstated
anything, I would like to hear about it. Thanks for your patience.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.