Navigation Services support extended to Customization:

Version History
Navigation Services for MacOS 8, 9 and X.

Version 3.0, September 14, 2002
--added a new class: NavCustomization that allows the client to customize a
NavDialog Window. To allow this, NavReply was extended with an additional
call: IsFolder. NavCustomization depends on usage of a DITL resource, and
for this a new plugin was designed: ResourceEdit Plugin. See the
documentation for this plugin, to obtain the details.

NavDialog Plugin:

Yes a bunch of classes have been implemented to support the Navigation
Services, but they all make sense. Let's go over them one by one starting
with probably the most important one. Don't make the mistake that one does
the actual saving or opening of a folderItem. This plugin supports the
Navigation DialogWindows and their manipulations. These manipulations are
the key to set the NavServices to your own needs. And that's what it's all
about. But why this plugin when REALbasic currently support some of these
manipulations? Well, for one thing, this plugin tries to support almost
every aspect of the Navigation Services. The classes have been numerous to
provide easy support with little or no coding required in the REALbasic
environment.

NavDialog:
The class that calls one of the Navigation Services, i.e., putting up the
window. The class has different methods to call the NavDialog Window and
has properties that allows you to determine what file(s) should be listed
you can determine with the NavTypeList class. You can further manipulate
the appearance of items in the NavDialog Window with the NavDialogOptions
class. The NavDialogOptions are numerous, i.e., you can define an extended
popupMenu, listing categories of FileTypes. This means that while the
NavDialog is up, you can adjust the filtering of files. Another important
property of the NavDialog class is the NavUserAction class. This class
messages the final reply to the Navigation Services in the form of a
NavReply class.

NavReply:
An instance of the NavReply class is obtained via the NavUserAction class.
NavReply can return multiple folderItems, depending how the NavDialog Class
was set up. In addition, NavReply can be obtained from the NavDialog.reply
property. Retrieval of the Reply in this case can be hazardous,
specifically in the OSX environment. The reason is the immediate returning
from the methods defined in NavDialog. It may be a difficult concept, but
immediate returning means that additional code after calling a method of
the NavDialog instance is already executed, while the user has not done
anything yet with the NavDialog Window. It's the carbon way. The classical
way does not deal with the immediate returning; Your code halts at the
method until the user has done something with the window. It would be a
very good habit to use the UserAction class to obtain the instance of the
NavReply, and it'll also work in the classic environment.

NavTypeList:
This class is used to provide a list of fileTypes the NavDialog Window
should expose to the user. it is up to you to populate this list, while you
also can omit the NavTypeList. It is specifically important when your
application has its own signature. The creator type becomes very important
in a build.

NavDialogOptions:
This class is required to drive the NavDialog Window into a cetain state.
The class has numerous methods to set a banner or message in the Navdialog
window, changing captions, setting the windowModality of the NavDialog
(MacOSX). This class also has another class as property,
NavDialogOptionsFlags, which is automatically instantiated when you
instantiate the NavDialogOptions class.

NavDialogOptionFlags:
A class that manipulates the behavior of the NavDialog window. The property
names in principle provide information about the effect it will have.

NavUserAction:
A class that provide access to the user action. If the user accepts a
Navigation dialog, one of the events is being fired, and you as the
programmer can respond accordingly. Why not having defined these events as
events of the NavDialog Class? Well, you can keep one instance of the
NavDialog Class, and exchange instances of NavUserAction.

NavCallback:

NavCallback provides additional info and manipulates a NavDialog. When
subclassed, you can block opening, or saving or block creation of a new
folder. You can monitor what files are being selected by the client, such
that when the client cancels the Navdialog, you still know what the last
folderitem was that was selected. NavCallback is a natural enhancement of
the Navigation Services the MacOS provides.

NavCustomization:

This class is required when the client wants to add additional controls in
the Navdialog. The class relies on usage of a DITL and a DLOG resource.
DITL is a list of dialog items, each of the items has a unique id, starting
with 1 for the first item. Navigation services, however, will offset these
id's by the number of navDialog items present. NavCustomization has
numerous methods to influence responses to the NavDialog; the events
provide information required to implement the customized behavior of the
Navdialog. You need to utilize the ResourceEdit Plugin to take advantage.

Sincerely,

Alfred N. Van Hoek, Ph.D. http://homepage.mac.com/vanhoek/