Re: NSArrayController selectNext updating late
Re: NSArrayController selectNext updating late
- Subject: Re: NSArrayController selectNext updating late
- From: email@hidden
- Date: Wed, 14 Sep 2005 06:54:08 -0500
Well, it's not so simple. I've got an array controller hooked up to a
pair of insert/delete buttons, so the methods are being used for the
GUI.
I want a newly-inserted object to have its text immediately selected
(within the cell) for editing (so the user can enter a real name
instead of the dummy text created in an -init method.
On Panther, the body of my array controller subclass' insert: method
looked like:
[tableView editColumn: 0 row: [tableView selectedRow] withEvent:
nil select: YES];
and now on Tiger I find I have to do something like this to handle
the built-in delay:
[NSTimer scheduledTimerWithTimeInterval: 0.01 target: tableView
selector: @selector(editNameOfSelection:) userInfo: self repeats: NO];
If I don't the table view ends up with the newly-inserted object
selected, but neither the table view nor anything else in the window
seems to have the focus -- requiring the user to click somewhere to
continue editing. It would be nicer if there were additional methods/
delegate callbacks so the application could respond to the insert-did-
finish-successfully case without blindly firing an invocation off
into the future.
And now I understand your concern over the possibility that insert:
fails due to some validation issue (not likely in my case, but in
general). Any idea how to determine if this in fact is the case (or
conversely, how to determine that it succeeded, since that's the case
I need to handle)?
----
Matt Holiday http://homepage.mac.com/matthol2/cocoa/
On Sep 14, 2005 Scott Anguish wrote:
Date: Wed, 14 Sep 2005 05:33:14 -0400
From: Scott Anguish <email@hidden>
Subject: Re: NSArrayController selectNext updating late
On Sep 13, 2005, at 8:21 AM, j o a r wrote:
On 12 sep 2005, at 10.44, Scott Anguish wrote:
In 10.4 the action methods are performed delayed, to allow for
sheets to be presented that can provide error feedback.
this is expected behavior.
...and properly documented, I'm sure?
Any method that delays it's execution is an exception to the norm
in my opinion, and non-default behaviour needs double-plus-good
documentation.
one other comment...
in general it's probably a bad idea to use the target-action
methods in any way other than as targets for UI items.
all of them can result in the selection attempting to change,
and this can be denied due to validation issues. unlike the other
selection, insertion and deletion methods, there is no bool to
indicate if it was successful in changing the selection. So you'll
not know if it failed, and the app might react strangely from the
user's perspective.
oh, and if you're changing the selection manually, check the
bool.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden