[iOliverC]

Hi guys,

I think a lot of the stuff I am about to post requires knowing where I put a lot of stuff, so I'll go into detail.

Basically, my goal here is to keep away from my document nib and its subclass. I want a totally separate nib and controller. My NSDocument subclass is basically a vanilla plain class, just implementing a few opening and saving methods. The application itself is really just a NSTextView with Undo turned on. I'll relate to the other, non-NSDocument class as otherClass from now on.

So basically, in the otherClass header, I add:

NSUndoManager *undoManager;

And in the implementation I add:

- (id)init
{
self = [super init];
if (self)
{
undoManager = [[[NSDocumentController sharedDocumentController] currentDocument] undoManager];
}
return self;
}

All well and good. Now I go about implementing Undo. Basically, I want to Undo/Redo a very basic operation, I am just taking some text and overwriting the NSTextView, this is in otherClass:

- (void)tidyDocument:(id)sender
{
untidyDocument = [[NSMutableString alloc] initWithString:@""];
[untidyDocument setString:[documentTextView string]]; // This is where I store the current document text before I change it. So I can undo/redo.
[self removeAllObjects:nil];
[self tidyHTML:[documentTextView string] inTextView:documentTextView reportErrorsIn:tidyTable];
}

Now I am going to implement the basic undo/redo methods needed:

- (void)tidyDocument:(id)sender
{
untidyDocument = [[NSMutableString alloc] initWithString:@""];
[untidyDocument setString:[documentTextView string]];
[self removeAllObjects:nil];

[[undoManager prepareWithInvocationTarget:self] untidyDocument:nil];
[undoManager registerUndoWithTarget:self selector:@selector(untidyDocument:) object:nil];
[undoManager setActionName:@"Tidy Document"];

[self tidyHTML:[documentTextView string] inTextView:documentTextView reportErrorsIn:tidyTable];
}

And now for my method that restores the NSTextView back to its original state:

- (void)untidyDocument:(id)sender
{
[[undoManager prepareWithInvocationTarget:self] tidyDocument:nil];
[undoManager registerUndoWithTarget:self selector:@selector(tidyDocument:) object:nil];
[undoManager setActionName:@"UnTidy Document"];

[documentTextView setString:untidyDocument];
}

So I build my app, and notice that when I do the tidyDocument: method, the Undo menu is still greyed out blank. I switch to the Document window, and check the menu again, its still greyed out and blank.

So I go into debug mode and do some NSLogging

And it seems that undoManager = (null). I can't see why it is null. Undo works like it should do for the NSTextView (things like 'Undo Typing' etc).

Any ideas appreciated,
Oliver

[Chuckit]

Without seeing everything you've done, I can't say with certainty, but my guess is that you haven't done anything to guarantee there is a current document when with object is created. In fact, that's really the behavior I would expect unless the creation of this object is tied to an awakeFromNib method or an action method from the nib somewhere.

[iOliverC]

Originally posted by Chuckit:
Without seeing everything you've done, I can't say with certainty, but my guess is that you haven't done anything to guarantee there is a current document when with object is created. In fact, that's really the behavior I would expect unless the creation of this object is tied to an awakeFromNib method or an action method from the nib somewhere.

Heres the weird thing, If I NSLog currentDocument when I have otherClass controlling a NSWindow, it returns null, but if I set otherClass to control a NSPanel, currentDocument returns something.

But undoManager still seems to be null no matter what. Also, I'm not really sure what you mean by "n fact, that's really the behavior I would expect unless the creation of this object is tied to an awakeFromNib method or an action method from the nib somewhere."

Thanks,
Oliver

[Chuckit]

Basically, I'm asking what the state of the app is when you create this OtherClass instance. Is it during document creation? Is it at startup? Shutdown? It's possible that you're instantiating it at a time when there is no current document unless you're very specific. I'd be more inclined to have it be created with an -initWithDocument: method or something like that, since it's tied to a document anyway.