Re: NSTableView reloadData question FOLLOWUP
Re: NSTableView reloadData question FOLLOWUP
- Subject: Re: NSTableView reloadData question FOLLOWUP
- From: Ondra Cada <email@hidden>
- Date: Thu, 11 Apr 2002 00:45:47 +0200
On Wednesday, April 10, 2002, at 10:39 , Bill Cheeseman wrote:
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.
Actually, the rules of "who, when, and why becomes the FR" are kinda
complicated, they depend on a number of conditions, and, moreover, they
changed substantially in a relatively recent past. I regret to say I am
not quite sure of them myself.
Though, before filling a bug, do please check the documentation to find
how the current situation does look. At the moment, I can just give some
generic hints:
(i) it is (in some cases) *perfectly reasonable* for an object to respond
to clicks, doubleclicks, and what-you-want, WITHOUT becoming the FR. There
are a number of examples of such behaviour (actually mostly I like that;
see also the comment below);
(ii) also, the kind of window in which the object happens to be is
important. Eg. in a utility window *NO* object should *EVER* become FR
(unless it contains the insertion point);
(iii) another thing worth to be checked is the keyboard control: it can be
activated/decativated, and it changes the FR behaviour substantially.
As for the actual NSTableView behaviour, I personally would prefer its
current behaviour: if I have a table and a textview in a window, and if
clicking to a column heading changes the sorting (which is both quite
common), I very definitely *NOT* want that re-sorting loses insertion
point in the textview -- which would be an inevitable result of its making
the NSTableView the FR!
OTOH, I can very reasonably imagine other cases, when the NSTableView
should be the FR (eg. to allow to use arrows to change its selection).
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
2K Development: email@hidden
http://www.2kdevelopment.cz
private email@hidden
http://www.ocs.cz/oc
_______________________________________________
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.