Re: Open/Save into packages?
Re: Open/Save into packages?
- Subject: Re: Open/Save into packages?
- From: email@hidden
- Date: Sat, 16 Feb 2002 12:09:28 -0800
What's the cheapest way to call NSSavePanel's
setTreatsFilePackagesAsDirectories: method?
I always want to pass the value YES, and *really* want to avoid
re-writing
any NSDocument or NSDocumentController methods. The default ones are
great!
Overriding them and calling
[[NSSavePanel savePanel] setTreatsFilePackagesAsDirectories:YES];
[super openDocument:sender];
for example doesn't work, because of course super calls [NSSavePanel
savePanel] too, which resets the parameters.
I was thinking that subclassing NSSavePanel and overriding +savePanel
would work, if (despite being warned against the method) my subclass
posed
as NSSavePanel.
I want application-wide functionality for both open and save, so this
would not be a problem. Can anybody suggest alternatives?
If it does what it says in the doc that it does, the
-prepareSavePanel: method should be exactly what you want. It's in the
NSDocument doc. It says:
Invoked by
runModalSavePanelForSaveOperation:delegate:didSaveSelector:contextInfo:
to do any customization of the save panel. Returns YES if successfully
prepared, and NO otherwise. The default implementation is empty and
returns YES.
So you just want to override that in your NSDocument subclass to do
what you want. If this didn't work for some reason, or if Apple had
simply not defined this method, then you might try putting a category
on - (BOOL)treatsFilePackagesAsDirectories; that simply returns YES,
like so:
@implementation NSSavePanel (MyPatches)
- (BOOL)treatsFilePackagesAsDirectories { return YES; }
@end
If Apple's code calls this method rather than just looking at the BOOL
ivar (and they're usually good about doing this), then this will suffice.
Posing is virtually never required by Cocoa. In all the years of
Cocoa / NeXTSTEP programming I've been doing, I have only written code
to do posing twice, and both times I quickly realized the error of my
ways and removed that code in favor of a better solution. A friend of
mine recently told me that he was very happy because he had reached the
point, in learning Cocoa, where he had learned to stop fighting Cocoa
and trust that it was well-designed, and that if something seemed really
hard to do, it was probably because he wasn't using the classes as
intended. That's very wise, I think.
That is not to say that posing is *never* needed. But it should not
be taken lightly. Probably thousands of apps (tens of thousands?) have
been written using the Cocoa frameworks. Whatever problem you've got
that you want to use Cocoa to solve, it's likely that someone at Apple
has already done the work necessary to ensure that that problem can be
solved gracefully. There are bases Cocoa simply doesn't cover, and
there are bugs in Cocoa, but by and large I think it is the case that if
you're having to resort to hacking with things like posing and other
ObjC runtime hackery, you're probably not approaching the problem right.
Sorry to be preachy, but apparently my previous lecture on posing
didn't "take" sufficiently... :->
Ben Haller
Stick Software
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.