Re: Leopard NSTableView Cell and single click editing
Re: Leopard NSTableView Cell and single click editing
- Subject: Re: Leopard NSTableView Cell and single click editing
- From: Corbin Dunn <email@hidden>
- Date: Wed, 05 Dec 2007 10:04:56 -0800
cted.
Are these things only happening in your app? Can you try them with
the
DragNDropOutlineView demo app? I don't see these things happening
there.
DragNDropOutlineView doesn't seem to have multiple selectable
columns, so I couldn't figure out how to compare it to mine. (But
see below.)
You mean multiple selectable rows, or columns? I'm guessing rows, and
I thought by default it allowed that. However, based on your lower
comments, it is irrelevant.
Possibly; the problems you are listing sound different than what I've
seen before. It is strange that single clicking on a non-selected row
would begin editing. It must first be selected before editing can
begin. So, something strange is happening in your app (maybe you
manually begin editing at some point?)
(Frankly, I haven't had to mess with this part of my code in well
over a year, so I had to refresh my memory of the details. It's
reasonably complex, but worked fine until y'all fixed all those
bugs...)
Digging around in my app, I see that I have an IBAction, -
tableViewHit:, that calls -editColumn:row:withEvent:select: if -
tableView:shouldEditTableColumn:row: returns YES--which it normally
does.
Under Tiger, -tableViewHit: gets called whenever the table is
clicked, regardless of which row is clicked.
It appears that, under Leopard, it doesn't get called if -
tableView:shouldEditTableColumn:row: returns YES and the active row
is clicked. However, it does get called if some other row is clicked.
Ah; so you are manually starting editing via the single click action;
I'm surprised this hasn't conflicted with NSTableViews starting of
editing before.
What do you recommend as the best approach for getting cells in a
Tiger-compatible database application to respond in a consistent
way, regardless of whether the clicked cell is in a selected row or
not? I'd prefer the Tiger behavior, for a variety of reasons.
Make the delegate method"tableView:shouldEditTableColumn:.." always
return NO. This refuses normal editing behavior. Then, in the
doubleAction, if the clickedRow/clickedColumn's are valid, begin
editing manually by calling editColumn:row:...
Under Leopard, setting -tableView:shouldEditTableColumn:row: to
always return NO causes -tableViewHit to be called every time the
table is clicked, regardless of whether the clicked row is active or
not. So I've done that.
This should also happen under Tiger; the 'action' is always sent when
the user clicks on something in the tableview, regardless of what it
clicked on.
I also set a doubleAction function.
The problem with this is that double-clicking produces the same
effect as single-clicking, leaving the field text unselected.
You mean, it doesn't start editing? Or it does start editing?
If my -tableViewHit calls -editColumn:row:..., then the the
doubleAction function never gets called. If I comment it out, then
the doubleAction function does get called.
You should set the doubleAction to something, say
"tableViewDoubleAction:", and in your implementation check to see if
the clickedRow/clickedColumn are valid, and if they are, then call -
editColumn:row:...
What you are seeing is expected; if the single click 'action' starts
editing, then the second click is sent to that edited cell, and not to
your table itself. Hence, you don't get a doubleAction.
Of course, that screws up a lot of how things work in my app, as the
-tableViewHit routine performs or calls a variety of functions that
don't work if -editColumn:row:... is not called at the right time in
the flow.
It sounds like you are expecting -tableViewHit (the 'action') to be
called on single clicking and double clicking, and sometimes you want
to begin editing and sometimes you don't. Exactly what things do you
need to do, and based on what user action. I'm getting confused to
exactly what your goal is, but if you help me understand, I may be
able to provide some better insight. For instance: You need X to
happen when the user single clicks. You need Y to happen when the user
double clicks. You want to start editing when Z happens.
I thought that maybe I should be doing something with -setAction,
instead, but in that case, double-clicking again fails to activate
the doubleAction routine. The action routine is called both for
single-clicks and for double-clicks. It looks like action and
doubleAction can't coexist--unless I'm missing some subtlety.
It can co-exist, and this was one of the main reasons we changed this
for Leopard. One can have a single 'action' perform editing, and the
double action do something else.
I definitely don't want my users to have to double-click to get at
the contents of a field. For one thing, if it causes the contents to
be selected, then if it contains a link, that link won't be
clickable, until the user clicks for a third time to deselect the
contents. (This non-clickability of highlighted text also seems to
be new with Leopard.)
This means that a user will require four mouse clicks to access a
link, vs. two clicks under Tiger. That's ain't gonna fly. We'd
already had complaints about requiring two clicks.
Can you post a screen shot of your UI or app somewhere so I can see
what you are attempting to do? Part of your problem may be solved by
calling 'selectWithFrame:' vs 'editWithFrame:' in the custom cell
subclass.
I think that, for now, I'm just going with single- and double-clicks
acting the same: activating the field and not selecting the text. If
the user needs the text highlighted, there's always command-A. It
seems to me that this will be more in line with our users'
expectations and past experience.
Since everything is fine in Tiger, I now test for the OS and -
tableView:shouldEditTableColumn:.. returns NO under Leopard, but
returns the result of a couple of tests under Tiger.
Other than the non-functioning double-clicks, the app now works
about the same under Leopard as under Tiger.
Let me know if this works well for you. Hopefully it is easy to do.
Another issue that I've just noticed is that if -
tableView:shouldEditTableColumn:row: returns NO, then tabbing no
longer moves to the next column. Instead, it just jumps to the next
NSTextView, as if there was only a single column. And backtabbing
simply deselects the current cell.'
Yes; unfortunately, the tabbing logic has to key off of something, and
that delegate method is one of the things it uses.
Is there a way to avoid that without having to handle tabs myself?
(Fortunately, my previous rev added new command keys to replace the
loss of traditional database tab and return functions in tables
under Leopard, so I guess we can live without tabs if we have to.)
Well, the only way is to return YES from the above delegate
method...but that may conflict with other things.
-corbin
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden