Re: Release memory
Re: Release memory
- Subject: Re: Release memory
- From: Chuck Hill <email@hidden>
- Date: Thu, 20 Jan 2005 08:14:49 -0800
Deleting needs an undo manager. Better is to add
ec.undoManager().removeAllActions() after (successful) calls to
saveChanges(). This lets the EC continue to function and avoids
carrying needless baggage (pre saved state) around.
try {
ec.saveChanges();
ec.undoManager().removeAllActions();
}
catch...
Chuck
On Jan 20, 2005, at 7:53 AM, James Seigel wrote:
To quote Dory, "LIttle red light going off".....I think there is a
problem with setting that to null, or it already is, or it resets it
to the default manager regardless. I believe what we did or
considered, was mocking up a dummy undo manager.
But....I could be way off base here....it is thursday after all.
Cheers
James
On 20-Jan-05, at 8:30 AM, Stephane Guyot wrote:
Perhaps
you can add : setUndoManager(null) on your editingContext.
If the application doesn't need undo at all, you can avoid any undo
overhead by setting the editing context's undo manager to null with
setUndoManager.
Have a look at :
http://developer.apple.com/documentation/WebObjects/Reference/API5.2/
com
/webobjects/eocontrol/concepts/EOEditingContextConcepts.html
Hope this help
Stephane
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
village.net
This email sent to email@hidden
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden