Re: Unique TIDs in OSX?
Re: Unique TIDs in OSX?
- Subject: Re: Unique TIDs in OSX?
- From: Arthur J Knapp <email@hidden>
- Date: Thu, 09 May 2002 12:50:12 -0400
>
Date: Thu, 9 May 2002 10:39:43 -0400
>
Subject: Unique TIDs in OSX?
>
From: Paul Skinner <email@hidden>
>
After hearing Nige comment on the slow speed of the 'Tell TIDs'
>
block, I looked into the whole issue of storing and resetting the TIDs.
>
I thought...AppleScript isn't multithreaded, how necessary is this
>
anyway? If I have any piece of code that uses TIDs I always set them
>
just prior to using them. How likely is it that another app could reset
>
them while I'm using them?
Another "app" cannot change the text item delimiters of the "current" app.
Each application maintains it's own "instance" of AppleScript. A saved
script application has no ability to modify AppleScript properties in any
other saved script application. This issue tends to get comfused because
of the state of things when one works in a script editor. The editing
application, (Script Editor, Script Debugger, etc...), mantains only one
"instance" of AppleScript, and therefore a change to the tids in one
script that you are editing will be reflected in every script that is
open in the editor.
The significance of the tids global persistence is simply a matter of
being consistent within any one script. Here are the common approches:
- Always set the tids before a coercion:
If you always set the tids before a coercion, then you never need to
worry about the state you are leaving them in. The only problem is that
one usually expects the tids to be in a given state, ie: {""}. When I
post a handler to the mailing list with this kind of code:
set myString to myList as string
I do so with the implicit understanding that the tids should be in their
default state.
- Always set the tids to a default after a coercion:
If you always set the tids to a default after having modified them, ie:
set text item delimiters to [whatever]
[do something involving the tids]
set text item delimiters to {""}
[or]
set text item delimiters to ""
then you can always be assured that the "basic" list to string coercion
will work as expected:
set myString to myList --> no need to worry about the tids
- Save and Restore:
Consider the possibilty that a scripter may have a very good reason to
want to keep the tids in a non-typical state most of the time. This might
be the case when someone is processing multiple lists returned from a
database and coercing them to tab or comma delimited strings. If a user's
code is all "inline", then this would not be such a big deal, as they
would probably just adopt one of the above methods. The real problem
occurs in larger projects where handlers, script objects, and loaded
script libraries are also used. These "independent" bits of functionality
would then need to have a cooperative means of ensuring that they were
not disturbing the user's desired tids.
The advantage of using save and restore is that it doesn't require a
generic handler or script object to have to know, (or care), anything
about the specific project script that is using it. It leaves everything
exactly the way it found it.
{ Arthur J. Knapp, of <
http://www.STELLARViSIONs.com>
<
mailto:email@hidden>
try
<
http://www.apple.com/applescript/>
on error number -128
end try
}
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.