Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!ucbvax!decwrl!labrea!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
Keywords: XCMD, hack, kludge
Message-ID: <1610@Portia.Stanford.EDU>
Date: 17 Apr 89 00:21:32 GMT
References: <6944@hoptoad.uucp> <2784@pegasus.ATT.COM> <6995@hoptoad.uucp> <1567@Portia.Stanford.EDU> <7020@hoptoad.uucp>
Sender: USENET News System <news@Portia.stanford.edu>
Reply-To: duggie@Jessica.stanford.edu (Doug Felt)
Organization: Stanford University
Lines: 67

In article <7020@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>In article <1567@Portia.Stanford.EDU> duggie@Jessica.stanford.edu (Doug Felt)
>writes:
>>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
>>...
>
>Well, but, a "user" should never see an XCMD.  It's a developer tool
>which is (or should be) only visible to the highest level of HC users,
>those who've clicked user level scripting.  Once you get to that
>level, there shoudn't be any problem with instructing the developer
>to use ResEdit.  You don't need to idiot-proof things by providing
>an HC installer.

I disagree.  First, there are users who do no appreciable amount of
scripting but who may still create simple stacks for their own use, by
cutting and pasting buttons, laying out fields, and the like.  They
interact with XCMDs by pushing buttons.  A simple example would be an
"Open" button which brings up the open file dialog and lets the user
launch an application.  A user who does no scripting, and does not
know how to use or even own Resedit, may yet wish to have this in her
or his Home or other stack.  An "Install" button is the best means of
getting it there.  Second, there are Hypercard "applications" that use
multiple stacks, and that share resources between stacks.  In this
case the user may never done so much as created a button or typed
"find" into the message window.  Again, such resources must be
installed into Hypercard or the Home stack, so an installer is
necessary.  And of course the installer must check for collisions with
existing resource names or ids.

>>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.

(I forgot the :-))

>The last sentence is too obviously screwy to bother refuting, but there
>is an interesting issue earlier on.  You can be internationalizable
>without being Script Manager friendly -- there are really two levels of
>international portability.  One is when you're compatible with other
>Indo-European languages that use one-byte-per-character alphabets and
>separate words using spaces; the other is where you're compatible with
>any language that can be crammed into the Script Manager.  The claimed
>HC incompatibility with the Script Manager may be real, but on the
>other hand, HC *is* pretty Europe-friendly.  Any developer who doesn't
>want to break this would be well advised to use separate strings.

I agree, although as one who works with languages "crammed into the
Script manager," I find partial internationalization unsatisfactory.
Rather like having an application 3/4 debugged :-).  But it may be the
best you can do, and if you anticipate users with native languages
different from your own, by all means use separate strings (and watch
out for number, date, time, and monetary formats, which might switch on
you).  On the other hand, if you don't plan on wide distribution and
want some string constants that only programmers will see--such as
returning the keyword "Error" at the start of an XFCN result string,
or named parameters to an XCMD--then embedded constants may be the
most expedient, if not the most professional, solution.

>Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim

Doug Felt
Courseware Authoring Tools Project
duggie@jessica.stanford.edu