=================== BUG #3797: LATEST MODIFICATIONS ================== http://savannah.gnu.org/bugs/?func=detailbug&bug_id=3797&group_id=99
Changes by: David Ayers <[EMAIL PROTECTED]> Date: Wed 07/09/2003 at 08:17 (Europe/Vienna) ------------------ Additional Follow-up Comments ---------------------------- Yesterday, Dirk and I did find out that EOEditingContext -hasChanges should also check the _unprocessedChanges/Deletes/Inserts (patch coming up). But the real issue, the update handling, is done through the NSUndoManager which currently isn't initialized for EOEditingContext. Initializing it, doesn't quite do the trick yet though. What seems to be missing in -[NSUndoManager registerUndoWithTarget:selector:object:] is a [[NSRunLoop currentRunLoop] performSelector:_loop target:self argument:nil order:NSUndoCloseGroupingRunLoopOrdering modes:NSDefaultRunLoopMode]. Yet I'm still unsure whether this is done uncondictionally. Still investigating.... =================== BUG #3797: FULL BUG SNAPSHOT =================== Submitted by: dlatt Project: GNUstep Submitted on: Thu 05/29/2003 at 09:58 Category: gdl2 Severity: 5 - Major Bug Group: None Resolution: None Assigned to: ayers Status: Open Summary: EOEditingContext, objectWillChange Original Submission: EOEditingContext should (according to the docs) add an invocation of -processRecentChanges to the end of the current run loop. This may probably be done like in EODelayedObserverQueue. Follow-up Comments ******************* ------------------------------------------------------- Date: Wed 07/09/2003 at 08:17 By: ayers Yesterday, Dirk and I did find out that EOEditingContext -hasChanges should also check the _unprocessedChanges/Deletes/Inserts (patch coming up). But the real issue, the update handling, is done through the NSUndoManager which currently isn't initialized for EOEditingContext. Initializing it, doesn't quite do the trick yet though. What seems to be missing in -[NSUndoManager registerUndoWithTarget:selector:object:] is a [[NSRunLoop currentRunLoop] performSelector:_loop target:self argument:nil order:NSUndoCloseGroupingRunLoopOrdering modes:NSDefaultRunLoopMode]. Yet I'm still unsure whether this is done uncondictionally. Still investigating.... ------------------------------------------------------- Date: Tue 07/08/2003 at 11:07 By: dlatt I am referring to the implementation of EOEditingContext's objectWillChange: method (didn't write it into the text because I thought it was sufficient to put it into the bug subject, sorry). It is not _really_ explicitly written in the reference, but the mechanism is mentioned in several places, e.g. EOF Developer's Guide pp 209-211. Perhaps the most obvious description is in the EOF Control Reference, page 5, last paragraph of "Tracking Enterprise Objects Changes". I interpret this in the way that in objectWillChange:, after doing its bookkeeping, the editing context should put a processRecentChanges invocation to itself at the end of the current run loop, so that the window can redraw all changes that occurred (this assumes using EOInterface). I can't compare with Apple's EOF, so this is only an interpretation of the docs, but as it's implemented now in gdl2, changes are not displayed if I don't add an explicit call to processRecentChanges in the application. I don't believe this is intended. The call to processRecentChanges in saveChanges is mentioned in the docs (see description of processRecentChanges in EO Control reference), but modifications in the object graph should be displayed in the user interface even if they are not yet saved (i.e., committed to the DB). Wait... maybe the issue that the display doesn't get refreshed has something to do with hasChanges, which displays the correct value only after processRecentChanges (this seems wrong, too?!). I can't examine MulleEOInterface now, will investigate this evening. ------------------------------------------------------- Date: Mon 07/07/2003 at 21:57 By: ayers Sorry for the long delay in looking into this. I tried to verify it a while back couldn't. Now I had some time to dig deeper. To which passages of the docs are you refering to? I don't see any queing of a -processRecentChanges in any run loop (at least not through the standard methods: performSelector:target:argument:order:modes:, performSelector:withObject:afterDelay: or performSelector:withObject:afterDelay:inModes:) during objectWillChange. (Testing with WO 4.5) It is directly invoked from EOEditingContext-_processEndOfEventNotification: somewhere during EOEditingContext-saveChanges. So, to me, our implementation seems correct. CC list is empty No files currently attached For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailbug&bug_id=3797&group_id=99 _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
