Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!shelby!Portia!Jessica!duggie
From: duggie@Jessica.stanford.edu (Doug Felt)
Newsgroups: comp.sys.mac.programmer
Subject: Re: XFCN/XCMD string in LSC C v3.0
Message-ID: <1567@Portia.Stanford.EDU>
Date: 14 Apr 89 17:52:46 GMT
References: <6944@hoptoad.uucp> <2784@pegasus.ATT.COM> <6995@hoptoad.uucp>
Sender: USENET News System <news@Portia.stanford.edu>
Reply-To: duggie@Jessica.stanford.edu (Doug Felt)
Organization: Stanford University
Lines: 27

The problem with using the resource id of the XCMD/XFCN resource as
the key to a corresponding STR# (or other) resource is that generally
when you copy resources the resource id gets reassigned.  Thus if you
distribute an XCMD in a stack with an "install" option you need an
installer XCMD that 1) lets you detect id conflicts and 2) lets you
assign ids explicitly.  The most common installers don't, and I had to
write my own in order to handle this problem.

If you don't plan on letting the user copy the XCMD then you have
complete control over the resource numbering and naming, so can use
whatever scheme suits you (as long as you use the 1 level deep
resource manager calls).

Multiple resources are also a problem if you plan on letting the user
switch stacks, which causes resource files to be closed.  You must
take care not to create data structures containing resource handles
that might persist over the closing of a stack.  Most XCMD's don't
do this so few people hit this problem.

I say go ahead and use embedded strings.  Hypercard is not really
script-manager friendly, and many stacks do lots of string munging
that is not fully language-independent.  When you get right down to
it, XCMDs are basically a hack. Lets not worry too hard about whether
we're following all the compatibility rules.

Doug Felt
Courseware Authoring Tools Project