Re: why won't this compile?
Re: why won't this compile?
- Subject: Re: why won't this compile?
- From: Paul Berkowitz <email@hidden>
- Date: Fri, 28 Dec 2001 14:19:02 -0800
On 12/28/01 1:38 PM, "Steven Angier" <email@hidden> wrote:
>
Paul Berkowitz wrote:
>
>
> On 12/28/01 12:36 AM, "Steven Angier" <email@hidden> wrote:
>
>
>
>> I think that it is much simpler to use the double-tell technique as this
>
>> works
>
>> reliably on
>
>> systems 7.5 and above (just make sure the first tell is to the variable):
>
>
>
> That's an old fairy-tale that has been disproved often (before the
>
> introduction of 'using terms from'), after a 2-year argument on MacScrpt.
>
>
It's not a fairy-tale. The simple fact is that the double tell works on all
>
systems from
>
7.5. You can use "using terms from" if you want, but if the double-tell works
>
on all
>
systems and "using terms from" doesn't, then why use the "using terms from"
>
technique? For
>
me it would mean re-working a lot of old code for no benefit.
>
>
And, in my experience, telling the local application name before telling the
>
variable can
>
cause the target applications to crash.
>
Sorry, Steve, I guess I wasn't clear. Yes, if you need to concern yourself
with OS versions before 9, then 'using terms from' will not do. You are
perfectly right. But the double-tell technique is flawed in some
circumstances, whereas the 'raw-code' technique always works. That's what
John Delacour's article, to which i supplied the URL, is very good at
explaining. There is a slightly different 'raw-code' technique that puts the
application name, rather than the application, as a variable. that is the
"Smile" or "Emmanuel Levy" version, which is neater and easier to use than
JD's <<class psn >> version. It can be found in the Smile Help: check under
"portability" or "raw code". I always found it the best and simplest such
technique before 'using terms from' came along.
For once, I have the luxury in writing now mostly for an OS X app of not
having to worry about this. Eventually, OS X will be a very useful cut-off
point.
--
Paul Berkowitz