Re: NSUndoManager in non-document based app using bindings
Re: NSUndoManager in non-document based app using bindings
- Subject: Re: NSUndoManager in non-document based app using bindings
- From: Dirk van Oosterbosch <email@hidden>
- Date: Thu, 16 Sep 2004 17:59:56 +0200
On 15-sep-04, at 22:22, mmalcolm crawford wrote:
[...] I gave the ExpensesAccount class an IBOutlet to NSTableView and
connected it in IB. Then I asked it (the NSTableView, which is
controlled by NSArrayController, right?) for an undomanager and
implemented the undo functionality in ExpensesAccount using that
manager. I don't like it, though, for it doesn't look like decent MVC
design at all. But hey, it works!
I'm not sure why the table view knows about the undo manager?
As suggested in the first reply, the undo manager should almost
certainly be a property of the application controller.
It still beats me too, but if I ask the NSWindow for an undomanager I
get (null). So you are suggesting I should put the calling of
NSTableView for the undoManager in AppController. Then connect the
ExpensesAccount to the AppController in IB and ask it (the
AppController) for an undoManager?
And what would be the correct relation between all those controllers?
(1. AppController as delegate of NSApp, telling ExpensesAccount to
load and save; 2. this ExpensesAccount holding the MutableArray and
3. NSArrayController controlling the TableView). Or should I move
code away from ExpensesAccount and put it in AppController?
Without knowing more about the functionality of ExpensesAccount it's
difficult to say.
Right now my ExpensesAccount
1. holds an NSMutableArray *expenses (which contains multiple instances
of Expense, the model, and which has the NSArrayController's
contentArray bound to it)
2. deals with all the undo functionality, similar to Hillegass's
example (chapter 7). With these methods:
-insertObject:inExpensesAtIndex:, -removeObjectFromExpensesAtIndex,
-startObservingExpense, -stopObservingExpense,
-changeKeyPath:ofObject:toValue:,
-observeValueForKeyPath:ofObject:change:context:
This code includes calling the NSTableView for its undoManager, like I
said above *and* setting the ActionName [undo setActionName:]
3. gets requests from AppController to load and save
4. does this loading and saving through calling NSArchiver and
NSUnarchiver with -archiveRootObject and -unarchiveObjectWithFile:
Look's like an awfull lot like a controller, doesn't it? Maybe I
*should* just call it ExpensesController...
Well, thanks a lot
Dirk
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden