Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!apple!portal!sv!news
From: leonardr@svc.portal.com (Leonard Rosenthol)
Newsgroups: comp.sys.mac.programmer
Subject: Re: New convention for owned resources--a proposal
Message-ID: <1990Oct17.173002.13966@svc.portal.com>
Date: 17 Oct 90 17:30:02 GMT
References: <2001.271ca261@waikato.ac.nz>
Sender: news@svc.portal.com
Reply-To: leonardr@svc.portal.com (Leonard Rosenthol)
Organization: Software Ventures Corporation.
Lines: 72

In article <2001.271ca261@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence
D'Oliveiro, Waikato University) writes:
> 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.
> 
	I, for one, have been trying to get Apple to adopt a generic form
of 'owned resources' for a long time.  XCMD's really brought the issue to
light as the need for users to be able to move associated pieces around,
as well as dealing with ID clashes is a REAL PROBLEM.

> 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.
> 
> [stuff removed to save space]
>
> 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".
> 
	Not a bad solution, within the current limitations of the Resource
Manager.  As a 'stop gap'  solution it might work - except for the problems
as outlined below.

> Additional notes:
>
> [more removed here]
>
> 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.
> 
	Herein lies the problem.  For many of the standard externals, the
calling application loads the resource, detaches it from the resource map
(either a simple DetachResource, or even HandToHand) and then executes it.
Hypercard 1.x, MicroPhone II 3.0 and other XCMD 1.x supporting apps do this,
and other types of externals as treated the same (White Knight, 4D, etc.)
So if the called piece of code is no longer in the resource map, how does
it get it's information to find the others?!?
	HC 2.0 solves this problem by NOT Detaching it - both for resource
management and debugging reasons, and other apps will follow (I hope), but
your method requires such a solution and for many apps this may not be an
acceptable one. 
	What we really need is Apple to fix the resource manager to provide
for some REAL form of owned resources - some form of Resource BNDL if you
will.  This BNDL can be used by Resource Movers, the calling application
and the external itself to find its owned resources.  We have been experimenting
with such a scheme in house for some work we are doing, and as long as you
can get your resource Info, then you can find the BNDL and all seems to work
quite nicely.  The advantage, or course, of the resource BNDL (needs a new
type though) is that there is no reliance on names or numbers, perse, just
a reference into the BNDL table.

--
Leonard Rosenthol
Software Ventures Corp.
MicroPhone II Development Team