Hey guys,
A little while back, I posted about a problem we were having with
calling undo after creating a new object. As you may recall, we were
experiencing an odd situation where after inserting a new object into an
editing context and then calling undo, the object would end up in the
'deletedObjects' list for the editingContext, but would not be part of the
registered objects list. This would then lead to a mess of other problems.
The problem was isolated to one part of our app, the calendar, and we just
uncovered the source of the problem, though not a full explanation for it.
The issue centers around the fact that EODisplayGroup registers its
own set of undos (For those of you who were unaware of this, you can watch
undo operations by calling 'defaults write MyApp EOFDebugUndo YES') when you
call insert:, insertObjectAtIndex:, and insertObject:atIndex:. In this one
instance, we were calling insertObject:atIndex:. As some of you may be
aware, when calling this method, the caller is expected to insert the object
in the editingContext by hand. What the documentation fails to mention is
that you need to insert the object into the editingContext before calling
insertObject:atIndex:. There is something in the way the undos are ordered
that creates a problem if you insert the object into the editingContext after
calling insertObject:atIndex:.
The problem that we see is that the displayGroup's delegate has the
opportunity to deny the insert of the object. This is why our code checked
to see if the insert in the displayGroup succeeded before inserting the
object into the editingContext. Unaware of this undo issue, this seemed like
the logical approach at the time.
There seem to be at least a couple workarounds for this issue. 1)
Use setObjectArray: instead of insertObjectAtIndex: (the problem with this is
that you lose the nice undo management which causes the object to be
reselected and reinserted into the displayGroup when you undo). 2) Assume
that the delegate will not deny the insert and stick the object in the
editingContext first. 3) Assume the delegate may deny the insert, but still
call [editingContext insertObject:anObject] first and then, if the delegate
refused, delete the object from the editingContext.
Regards,
Paul
---
Paul Summermatter
LGS Systems, Inc.
Medical Computing Division
15 TJ Gamester Ave
Portsmouth, NH 03801-5871
(603) 433-9822 voice
(603) 433-9818 fax
(888) 898-6321 pager
[EMAIL PROTECTED] paging email
[EMAIL PROTECTED]
(NeXT or MIME Mail Welcome)
http://www.lgs-systems.com
