Convert a List to a String

[Shane_Stanley]

@McUsrII

it isn’t only Script Editor that creates a new instance of AppleScript for a single script. (I tested it in Script Debugger).

Right. But SD keeps the same instance for the life of a document, whereas Script Editor creates a new one for each compile (although this can be changed by a hidden setting)

[Nigel_Garvey]

@McUsrII

@Nigel Garvey

One thing about setting things by list (and the reason it can’t be used to make a one-liner here) is that all the values in the right-hand list are got at the same time and are THEN applied to the items in the left-hand list. So if you’re of an obfuscationist turn of mind, you can often arrange the lists in non-intuitive ways:

set theList to {"a", "b", "c"}

set {text item delimiters, TID} to {",", text item delimiters}
set {text item delimiters, theListAsString} to {TID, theList as text}

theListAsString --> a,b,c

[msh’s comment snipped]

Just for the record, that wasn’t the original code that Nigel Garvey posted in post #7. The code above, does things in the wrong order, first you save the tids, then you set them, then you coerce something to text, and then you restore them.

Just to clarify this: what McUsrII describes is the conventional way of thinking about the process. The obfuscated code here (which I don’t encourage anyone to use) is exactly like my post #7 code in that it firstly gets all the values from the right-hand lists and then sets the variables in the left-hand lists to the results. The variables are indeed set in the reverse order within the lists, but the overall effect’s the same: set the tids to a new value, store their old value in TID, restore the tids to their original value, set theListAsString to the result of coercing theList to text while the tids were at the new value.

[msh]

@McUsrII

However, there is a good readup on variable types here. I also think, that with AppleScript vesion 2.3 the text item delimiters are reset to whatever they was, when a script has finished executing, so nowadays, only three lines are needed, or one line, if that it is the only usage of a text item delimiter in a script.

set ml to {"a", "b", "c"}
set {text item delimiters, newText} to {", ", (items of ml as text)}

(bold set by me)

Yay! That’s my first thought, though I still haven’t plunged into the docs.

So ASTID’s scope is the editor or running script application (and by that I hope the docs imply program). In my case, I need a quick fix to convert some items, one time, so that one liner works great. Btw, items of is not necessary.

[McUsrII]

@msh

@McUsrII

However, there is a good readup on variable types here. I also think, that with AppleScript vesion 2.3 the text item delimiters are reset to whatever they was, when a script has finished executing, so nowadays, only three lines are needed, or one line, if that it is the only usage of a text item delimiter in a script.

set ml to {"a", "b", "c"}
set {text item delimiters, newText} to {", ", (items of ml as text)}

(bold set by me)

Yay! That’s my first thought, though I still haven’t plunged into the docs.

So ASTID’s scope is the editor or running script application (and by that I hope the docs imply program). In my case, I need a quick fix to convert some items, one time, so that one liner works great. Btw, items of is not necessary.

You have to realize, it is a dangerous habit, no errors are as easy to commit as copy & paste errors, I guess that the Script Runner of Script Menu also runs its scripts in a new AppleScript Component, but at least it wasn’t like that, and you have no idea how the different script runners of the applications are implemented really, so not making a habit of resetting the text item delimiters, is like wanting to live hazardously.

The reference, is by the way, more about how the aggregate data types, like list and records works, by no means the complete story, but it may explain why setting a variable referenced by a list may take longer time, (because of the dereferencing). -It is funny though, that using a reference, when getting a value from something, actually may speed up access.

[msh]

That one-liner doesn’t work the first run actually, but the second one. So there’s an order of processing, instead of sort of swapping the values at once. I’ll stick to the 2-liner and ASTID resetting.

[Nigel_Garvey]

If you’re desperate for a one-liner, with no regard for any semblance of efficiency:

set theList to {"a", "b", "c"}

set theListAsString to (run script ("on run {l, d}" & linefeed & "set text item delimiters to d" & linefeed & "l as text" & linefeed & "end") with parameters {theList, ","})

The text script apparently has its own instance of AppleScript and doesn’t affect the main script’s tids, so it doesn’t need to restore them.

OK. The text is really four lines. But hey.

[msh]

@Nigel Garvey

OK. The text is really four lines. But hey.

I love this site :lol:

[kel1]

Hi msh,

Note that you don’t need to reset the text item delimiters if your app closes. Just a note that they changed that.

gl,
kel

[kel1]

Hi,

Note that it is a good idea to do it but, it won’t cause bugs if your app is rerun.

gl,
kel

[TecNik]

Wow! Went home Friday night and came in this morning to quite a read.

Please can someone list the example that won’t easily get you into hot water, is backwards compatible, we would be encouraged to use, doesn’t rely on SD or AS Editor to reset/remember what TIDs you’ve set etc and isn’t necessarily a one-liner.

Thanks guys

[DJ_Bazzie_Wazzie]

@kel1

Note that it is a good idea to do it but, it won’t cause bugs if your app is rerun.

That’s actually not the reason to set the text item delimiters to the old values, otherwise you could set text item delimiters just to “” instead of the previous value. The reason to set text item delimiters back to the old value is when you’re using handlers who has different text item delimiters set but does make an call to the other handler. Here a small example:

set theString to "replace this for that
replace this for that
replace this for that
replace this for that"

handler1(theString)

on handler1(str)
	tell AppleScript
		set oldTIDs to text item delimiters
		set text item delimiters to linefeed
		set TIs to text items of str
		repeat with i from 1 to count TIs by 2
			set item i of TIs to my handler2(item i of TIs)
		end repeat
		set str to TIs as string
		set text item delimiters to oldTIDs
	end tell
	return str
end handler1

on handler2(str)
	tell AppleScript
		set oldTIDs to text item delimiters
		set text item delimiters to "this"
		set TIs to text items of str
		set text item delimiters to "that"
		set str to TIs as string
		set text item delimiters to oldTIDs
	end tell
	return str
end handler2

If you don’t set the text items back properly the code will give unexpected results and will use the text item delimiter of the wrong handler to coerce the list into a string.

@kel1

Note that you don’t need to reset the text item delimiters if your app closes. Just a note that they changed that.

AFAIK That has always been the case, the only difference between Mac OS X and Mac OS system is that script editor will use a new AppleScript component between each compile while in Mac OS it did not. Here some code to test for yourself:

if (AppleScript's text item delimiters) as string is equal to "" then
	log "new scripting component"
	set AppleScript's text item delimiters to "delimiter"
else
	log "same scripting component"
end if

[TecNik]

… and the preferred/encouraged method, please?

[McUsrII]

@TecNik

… and the preferred/encouraged method, please?

The preferred method is to set the delimiters back to their previous value within the handler/scope they were changed. That is the only way that guarantees that operations considering them will be without unwanted side-effects at all times.

@DJ Bazzie Wazzie

AFAIK That has always been the case, the only difference between Mac OS X and Mac OS system is that script editor will use a new AppleScript component between each compile while in Mac OS it did not. Here some code to test for yourself:

This is true. What I’m even more concerned about, is whether a new scripting component is used when a script from the script menu is run. I experienced problems with this in Tiger, but, I still believe it is up to the App Developer how they implement their own script menu, so, it is really up to them how they distribute any scriping components. That is also a reason for restoring the text item delimiters.

[TecNik]

Thanks McUsrII !

[DJ_Bazzie_Wazzie]

@TecNik

… and the preferred/encouraged method, please?

How you write it down can be arguable (using a tell block or not, etc) but either way it has to be something like:

set theList to {"a", "b", "c"}
return join(theList, ", ")

on join(lst, sep)
	tell AppleScript
		set oldTIDs to text item delimiters
		set text item delimiters to sep
		set str to lst as string
		set text item delimiters to oldTIDs
	end tell
	return str
end join

[TecNik]

Thanks DJ.

[DJ_Bazzie_Wazzie]

@McUsrII

That is also a reason for restoring the text item delimiters.

True, the reason is that one code cannot ruin the other. Script editor can run two script simultaneously by using a scripting component for each document. However, applications like QuarkXPress who uses one scripting component for all scripts cannot. Therefore scripts for the QuarkXPress scripting menu always begins with set applescript’s text item delimiters to “”. To make sure a crashed script from a previous run doesn’t ruin my code.

[TecNik]

@DJ Bazzie Wazzie

However, applications like QuarkXPress who uses one scripting component for all scripts cannot. Therefore scripts for the QuarkXPress scripting menu always begins with set applescript’s text item delimiters to “”. To make sure a crashed script from a previous run doesn’t ruin my code.

Have experienced that a few times, in my earlier scripting years, when writing script for QuarkXpress!
Live ‘n’ learn!

[McUsrII]

@DJ Bazzie Wazzie

@McUsrII

That is also a reason for restoring the text item delimiters.

True, the reason is that one code cannot ruin the other. Script editor can run two script simultaneously by using a scripting component for each document. However, applications like QuarkXPress who uses one scripting component for all scripts cannot. Therefore scripts for the QuarkXPress scripting menu always begins with set applescript’s text item delimiters to “”. To make sure a crashed script from a previous run doesn’t ruin my code.

Yes, I have started to use Smile from Satimage now, which is an ideal piece of software, if you intend on using AppleScript as a very primitive alternative to MatLab, and similiar, that is, use AppleScript as a computing enviroment, like a basic interpreter if you like. Smile now comes as SmileLab, for free, with plotting and drawing facilities, with the ability to generate pdf good looking images, for free.

Smile uses only 1 scripting component, (so libraries are loaded globally), at least for the AppleScript terminal windows, it doesn’t use AppleScript version 2.3 either, not yet anyways. But given drawing, plotting, and rs232 support -for free, I am forgiving.

[msh]

@TecNik

… and the preferred/encouraged method, please?

Summary (pick your poison)

McUsrII’s #4 (4 lines, 4 assignments)
Nigel Garvey’s #7 (2 lines, 4 assignments + 2 lists, µsec slower)
McUsrII’s #17 (1 line, works only the 2nd run, not recommended)