bugGNUstep - Bugs: bug #3797, EOEditingContext, objectWillChange

Group
 
 

bug #3797: EOEditingContext, objectWillChange

Submitter:  Dirk Lattermann <dlatt>
Submitted:  Thu 29 May 2003 07:58:13 AM UTC
   
 
Category:  gdl2 Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  ayers
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 22 Jan 2008 02:46:50 PM UTC, comment #9: 

All current test cases wrt to -hasChages pass.

David Ayers <ayers>
Group Member
Wed 09 Feb 2005 01:09:01 PM UTC, comment #8: 

I could really use a testcase that displays the issue you're still having with -hasChanges.

David Ayers <ayers>
Group Member
Fri 04 Feb 2005 07:20:17 PM UTC, comment #7: 

Thank you, David, for your impressive work!
I tried the situations which led me to the bug report in the first place, and it works better. Especially, hasChanged now yields the correct value when there weren't any changes in the editing context and when there are unsaved changes. I don't need to call processRecentChanges explicitly any more.

However, when there were changes that have been saved, hasChanges still returns YES, so some state is not reset as it seems.

I didn't test much else, but from "normal" usage (not including the redo stuff) while playing around with gdl2, it seems usable. Thanks again!

Dirk Lattermann <dlatt>
Thu 03 Feb 2005 06:44:23 PM UTC, comment #6: 

This should finally be fixed in CVS.  Much of EOEditingContext has been rewritten and there are certainly still lots of holes.  I'll try to fill them as time permits.  I'll makr this report for "Testing" for about a week and then close it if I don't get any feedback.

David Ayers <ayers>
Group Member
Tue 15 Jul 2003 12:12:00 PM UTC, comment #5: 

Removed the temprary base.patch as it's been superceeded with the cvs version of -base.

David Ayers <ayers>
Group Member
Wed 09 Jul 2003 12:57:39 PM UTC, comment #4: 

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 :-( .

David Ayers <ayers>
Group Member
Wed 09 Jul 2003 06:17:01 AM UTC, comment #3: 

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....

David Ayers <ayers>
Group Member
Tue 08 Jul 2003 09:07:16 AM UTC, comment #2: 

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.

Dirk Lattermann <dlatt>
Mon 07 Jul 2003 07:57:38 PM UTC, comment #1: 

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.

David Ayers <ayers>
Group Member
Thu 29 May 2003 07:58:13 AM UTC, 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.

Dirk Lattermann <dlatt>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #516:  gdl2.patch added by ayers (4KiB - application/octet-stream - Temporary Patch for -gdl2)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ayers (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-01-22 ayers Open/ClosedIn Test Closed
    2005-02-03 ayers Item GroupNone Bug
        StatusNone Fixed
        Open/ClosedOpen In Test
    2003-07-07 ayers Assigned toNone None

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code