NSPersistentDocument saving problem

FROM : Daniel Wambold
DATE : Wed Jan 16 23:03:22 2008

Hello. I have written a relatively simple NSPersistentDocument 
application that uses CoreData to keep track of clients and specific 
events belonging to a given client. For some reason, if I open a file 
(say, by double-clicking it in the Finder) and immediately press Apple-
s to re-save it, the file becomes zero bytes (in the Finder) and is 
unreadable. However, if I click on the data in the table views (the 
clients, for example, which causes the event list to update in the 
adjacent table view), THEN press Apple-s, it saves properly. It even 
over-writes the zero-byte file with the correct data if I didn't quit 
in the interim.

I have not altered any of the saving routine except to override the -
(IBAction) saveDocument:(id)sender method to post a notification to 
commit editing (done in another object) before invoking [super 
saveDocument:sender]. When the program is first launched, data (client 
names and the events belonging to the client at the top of the list) 
are shown in the UI in their respective table views, so at least SOME 
data are being read from the file at the program's launch. Any 
thoughts on this odd behavior would be greatly appreciated.

More info that might help diagnose this problem: The App's window has 
a space for free text entry (it's a scroll view) that's associated 
with each Event item. If, after opening a file, I click in this window 
and edit the text, Undo is not available. If I then click on the 
associated Event or Client in the event or client scroll view, Undo 
becomes available and will undo the typing that had been done before 
the click. I don't know if this helps shed light on my problem, but I 
hope I can get to the bottom of this. (Is there something about the 
way faults are detected when using CoreData that might lead to this? I 
almost think it's behaving as though some internal pointers to the 
actual data have not been initialized, but by clicking on something, 
they suddenly have the correct values, allowing the UI undo and saving 
routines to work properly....) Thanks! -Dan