Re: Enabling File Open/Save etc in a non-document-based application

FROM : Quincey Morris
DATE : Wed Apr 16 18:37:07 2008

On Apr 16, 2008, at 03:01, Roland King wrote:

> I think perhaps I'm not being clear in what I'm asking.
>
> The File Open (for instance) menu item is already assigned, it sends 
> openDocument: to FirstResponder. I can see it right there in the 
> bindings, that menu item is already set up to call something.
>
> Yes I suppose I could write my own entirely different method which 
> pops up a file chooser, then waits for user input and displays the 
> results, but that doesn't seem to be using the framework, I want it 
> to pop up the open file dialog (like it usually does) and just hand 
> me the filename in a callback later. But is that plumbing only 
> available automatically in document-based applications.


There are 5 conceptual pieces involved in doing this:

1. The target/action mechanism. You can re-use an action method name 
that's otherwise unused in your application (such as openDocument: in 
this case) or choose your own. (BTW, the link from a user interface 
item to the target is called a "connection", not a "binding". Bindings 
are something different.)

2. The application delegate object. This is often a convenient place 
to implement action methods that are not specific to a window. Create 
an instance of the application delegate (which you define) by using 
Interface Builder to put it in the main NIB file (the one with the 
main menus in it).

3. The responder chain. The application delegate is in the responder 
chain for actions. Or, you can target the application delegate 
directly, and ignore the responder chain.

4. Class NSOpenPanel or NSSavePanel, to display one of the 2 kinds of 
file dialogs.

5. User interface validation, to make sure your menu item is enabled 
at the right time. In this case, the menu item should likely be valid 
all the time, and merely implementing the action method is enough to 
get it enabled.