Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!comp.vuw.ac.nz!waikato!ldo
From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
Newsgroups: comp.sys.mac.programmer
Subject: New convention for owned resources--a proposal
Message-ID: <2001.271ca261@waikato.ac.nz>
Date: 17 Oct 90 05:26:41 GMT
Organization: University of Waikato, Hamilton, New Zealand
Lines: 87

I've been writing some HyperCard externals (XCMDs and XFCNs) which
need to have associated message strings and dialogs and things. I
want these bits of data to be "localizable" via ResEdit or whatever,
which tends to rule out embedding them in the code.

Obviously, we need a scheme for associating these string, dialog
and other resources with the code they belong to.

The Resource Manager provides two ways of identifying resources:
by name, and by ID number.

There is a current scheme for associating owned resources with
certain kinds of code resources, based on using reserved ranges
of ID numbers. This scheme is extremely limited in a) the kinds
of code it applies to, and b) the number of owned resources you're
allowed to have. 16-bit ID numbers simply don't give you enough
room to expand this scheme in any sensible fashion.

The only thing left to do is adopt some convention using resource
names. These names can be up to 255 characters long, which should
be enough if you set them up carefully...

My proposal is to use a "qualification" scheme, where you use
the name of the code resource, followed by a name private to
that particular piece of code, for identifying the owned resources.
You'll need some kind of delimiter for separating the parts of
the name: I propose using the colon, as there is already a precedent
for the special treatment of this character, in pathnames in
the file system.

Example: I have a HyperCard 2.0 XCMD which puts up a modeless
dialog in its own window. While the window is up, you can get
and set several of its properties with the appropriate HyperTalk
commands. To make it easier for my XCMD to be adapted for non-English
speakers, I would like to keep the list of property names in
a 'STR#' resource, and of course define the dialog in a DLOG
and DITL resource.

Supposing the XCMD is called "Fred" (this is only an example,
remember). Then, the STR# resource could be named "Fred:Properties",
and the DLOG and DITL could both be called "Fred:Dialog".

Additional notes:

When copying the external to a different stack, the copying utility
would note the name of the external, and then it would have to
scan *all* the resources in the source stack, looking for ones
with names beginning with (in this case) "Fred:". Potentially slow,
I know.

The resources are liable to be renumbered to avoid clashes with
existing resources in the destination resource file. The copying
utility would probably do what Font/DA Mover does now, and check
for certain standard resource types which contain embedded references
to other resource IDs, and update them accordingly.

It may be possible for the code resource to be renamed, so long as
the prefix part of the names of its owned resources is updated
to match: if I change the name of the XCMD to "Mork", then
its owned resources would become "Mork:Properties" and "Mork:Dialog".
The part after the colon must *not* be changed.

When the code is trying to access its owned resources, it must
first find out its own name (in many contexts, code resources can
just do a RecoverHandle on themselves followed by a GetResInfo,
while HyperCard 2.0 provides a GetXResInfo callback which will
do the trick), and use that as a prefix for forming the names of
its owned resources. For instance, my XCMD example would take
its name, and append a colon and the word "Properties" (this
string would be embedded in the code), and then it could do
a GetNamedResource to find its property names.

If the code has any custom resource types which reference
other owned resources, they must do so by name. The name would
be just the part after the colon, and the code resource would
have to build this into a full name using a similar technique
to the one described in the previous paragraph.

What do other people think? Do these ideas make sense? Are
there any better approaches? Is there anybody else in the
world who thinks this is a problem?

Lawrence D'Oliveiro                       fone: +64-71-562-889
Computer Services Dept                     fax: +64-71-384-066
University of Waikato            electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
Y-axis fanatics look down on negative numbers.