Re: NSUndoManager & NSTableView editing
Re: NSUndoManager & NSTableView editing
- Subject: Re: NSUndoManager & NSTableView editing
- From: James DiPalma <email@hidden>
- Date: Fri, 27 Sep 2002 01:14:27 -0400
From: Bill Cheeseman <email@hidden>
From: Pete Yandell <email@hidden>
Doesn't help! If I put a [[tableView window] makeFirstResponder:nil]
in the action method for my "add row" button, the graceful end to the
editing gets grouped in with the creation of the new row as far as the
undo manager is concerned. As long as they both happen within the one
cycle through the runloop they're going to be grouped, right?
Interesting. Well, all I know is that my app correctly distinguishes
between
editing actions and row adding and deleting actions for purposes of
the undo
manager. I record adding and deleting rows with the undo manager
separately
from recording data changes to a row that's being edited. And I'm
careful to
make sure I force live editing sessions in one row to come to an end
before
another row gets added or deleted.
Great. If you have an application where undo operations are isolated
into separate undo groupings, then we can probably figure out how your
app behaves differently even though Pete describes a nearly identical
set of user actions and program execution.
Can you do me a favor and set breakpoints at these points:
-[NSUndoManager beginUndoGrouping]
-[NSUndoManager endUndoGrouping]
and then begin editing a cell in your tableview, and then press a
button that adds a row to your tableview. Then list each time one of
these breakpoints hits. You should get 2 begins and 2 ends before
normal operation of your program resumes. It might be interesting to
see a partial backtrace for each of those breakpoint hits.
Here is a backtrace from my sample application that shows where Pete
and I are seeing problems:
#0 0x908368c4 in -[NSUndoManager beginUndoGrouping] ()
#1 0x908367e4 in -[NSUndoManager(NSUndoManagerPrivate)
_prepareEventGrouping] ()
#2 0x0000454c in -[NumberModel setNumber:]
#3 0x00004fbc in -[NumberInspector setNumber:]
#4 0x930cfe2c in -[NSApplication sendAction:to:from:] ()
#5 0x9315bff0 in -[NSControl sendAction:to:] ()
#6 0x932eefc8 in -[NSTextField textDidEndEditing:] ()
#7 0x1f008c7c in -[JimQuietTextField textDidEndEditing:]
#8 0x907eaf7c in _nsNotificationCenterCallBack ()
#9 0x90168b18 in CFStorageDeleteValues ()
#10 0x90166238 in _CFNotificationCenterPostLocalNotification ()
#11 0x9331ca98 in -[NSTextView(NSSharing) resignFirstResponder] ()
#12 0x9336a798 in -[NSWindow makeFirstResponder:] ()
#13 0x1f0072a8 in -[JimInspector endEditing]
#14 0x00004e50 in -[NumberInspector round:]
round: is my button's action message, which uses [window
makeFirstResponder:window] to end editing, which is exactly what you
suggested in your first post on this thread, so we are probably all
doing something very similar. This backtrace shows that AppKit has no
opportunity to endUndoGrouping twice during -[NumberInspector round:].
Pete sums it up nicely:
As long as they both happen within the one cycle through the runloop
they're going to be grouped, right?
Since your application is "correctly distinguishes between editing
actions and row adding", you should have a different backtrace that
will help us figure out what your app is doing differently.
I must be doing something differently from your application; here are
some specifics of my application:
- bordered, push button type NSButton to simulate add-row action
- action method for button calls [window makeFirstResponder:window]
- editable textfield used to simulate a tableview editing
- no applescripts involved
I think you are using an NSTableView with editable cells; could this be
it? Pete uses an NSTableView too, both use a field editor, and I'm
using a textfield that sends action on endEditing (Does tableview
editing work similarly?). I think these two controls behave enough
alike that something else must be different.
Does your action method for adding a row call abortEditing? You suggest
it might with:
I do it in an analogous row deletion scenario by calling NSControl's
abortEditing.
But also state:
I'm careful to make sure I force live editing sessions in one row to
come to an end before another row gets added or deleted.
So, you must not be throwing out uncommitted row edits with
abortEditing. Anyway, Pete is doing these things: starting an add-row
action, ending field editors edits, registering undo for row editing,
adding a row, and registering undo for add-row. Pete ends up with one
undo grouping for both edits; are you doing these same steps and also:
correctly distinguish[ing] between editing actions and row adding and
deleting actions for purposes of the undo manager.
If so, you are getting 2 beginUndoGroupings and 2 endUndoGroupings to
happen during a single button press. I look forward to seeing your
backtraces.
-jim
_______________________________________________
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.