[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #3797] EOEditingContext, objectWillChange
From: |
nobody |
Subject: |
[bug #3797] EOEditingContext, objectWillChange |
Date: |
Wed, 09 Jul 2003 08:57:42 -0400 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 |
=================== BUG #3797: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=3797&group_id=99
Changes by: David Ayers <d.ayers@inode.at>
Date: Wed 07/09/2003 at 14:57 (Europe/Vienna)
------------------ Additional Follow-up Comments ----------------------------
I've attached two patches to the bug report, one for -base and one for -gdl2
which currently "fix" the problem. The patch for -base defines and uses
NSUndoCloseGroupingRunLoopOrdering. The patch for -gdl2 also uses the
NSUndoCloseGroupingRunLoopOrdering in the EOUndoManager's implementation of
registerUndoWithTarget:selector:object: after calling super, to register a call
to _loop: with the run loop. I would need someone with OS X to verify whether
this actually belongs on NSUndoManager as WO4.5 suggests (and I still need to
figure out whether this truely called unconditionally, when I find the time.)
The -gdl2 patch also
- fixes the -hasChanges implementation of EOEditingContext to include checks
for _unprocessedChanges/Deletes/Inserts,
- initializes the EOUndoManager instance for an EOEditingContext,
- sets the event grouping instead of querying it and ignoring the return value
in _enqueueEndOfEventNotification,
- adds an empty implementation of _clearChangedThisTransaction: which is setup
during processing and
- invokes _enqueueEndOfEventNotification in objectWillChange: the first time
the object is changed and not just on subsequent changes.
PS: Sorry for the bandwidth. I was hoping merely adding files to the report
wouldn't trigger messages to bug-gnustep. I guess I was wrong :-( .
=================== 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 14:57 By: ayers
I've attached two patches to the bug report, one for -base and one for -gdl2
which currently "fix" the problem. The patch for -base defines and uses
NSUndoCloseGroupingRunLoopOrdering. The patch for -gdl2 also uses the
NSUndoCloseGroupingRunLoopOrdering in the EOUndoManager's implementation of
registerUndoWithTarget:selector:object: after calling super, to register a call
to _loop: with the run loop. I would need someone with OS X to verify whether
this actually belongs on NSUndoManager as WO4.5 suggests (and I still need to
figure out whether this truely called unconditionally, when I find the time.)
The -gdl2 patch also
- fixes the -hasChanges implementation of EOEditingContext to include checks
for _unprocessedChanges/Deletes/Inserts,
- initializes the EOUndoManager instance for an EOEditingContext,
- sets the event grouping instead of querying it and ignoring the return value
in _enqueueEndOfEventNotification,
- adds an empty implementation of _clearChangedThisTransaction: which is setup
during processing and
- invokes _enqueueEndOfEventNotification in objectWillChange: the first time
the object is changed and not just on subsequent changes.
PS: Sorry for the bandwidth. I was hoping merely adding files to the report
wouldn't trigger messages to bug-gnustep. I guess I was wrong :-( .
-------------------------------------------------------
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
File Attachments
****************
-------------------------------------------------------
Date: Wed 07/09/2003 at 14:32 Name: base.patch Size: 1KB By: ayers
Temporary Patch for -base
http://savannah.gnu.org/bugs/download.php?group_id=99&bug_id=3797&bug_file_id=518
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 #3797] EOEditingContext, objectWillChange, nobody, 2003/07/07
- [bug #3797] EOEditingContext, objectWillChange, nobody, 2003/07/08
- [bug #3797] EOEditingContext, objectWillChange, nobody, 2003/07/09
- [bug #3797] EOEditingContext, objectWillChange, nobody, 2003/07/09
- [bug #3797] EOEditingContext, objectWillChange, nobody, 2003/07/09
- [bug #3797] EOEditingContext, objectWillChange,
nobody <=
- [bug #3797] EOEditingContext, objectWillChange, nobody, 2003/07/09
- [bug #3797] EOEditingContext, objectWillChange, nobody, 2003/07/09
- [bug #3797] EOEditingContext, objectWillChange, nobody, 2003/07/15