text item delimiters don't work for me anymore

[Motti.Shneor]

Hi.
Consider the following simple action handler of my script:

	on myAction_(sender)
	   set myText to "Wish/I/Could"
           set text item delimiters to {"/"}
	   log text items of myText
	   return
	end myAction_

The following will always break the text into single character list.
{“W”,“i”,“s”,“h”,“/”,“I”,“/”,“C”,“o”,“u”,“l”,“d”} — NOT what I meant.

The same very script, when run from AppleScript Editor, will correctly break the text into
{“Wish”, “I”, “Could”}

I thought maybe it’s a target problem, so i tried to

           set my text item delimiters to {"/"}

and then I read something I did not quite understand about user identifiers in AppleScriptObjC, so I tried

           set |text item delimiters| to {"/"}

to no avail.
I think someone in the AppleScriptObjC framework, or cocoa application “eats” my command, and for some reason, the command no longer applies to the script, or to subsequent actions like the “text items of”.

Please help… I have a rather big application that works nicely as script in AppleScript Editor, but I can’t merge it into the real cocoa application!

[elspub]

I always use

Applescript’s text item delimiters

not

my text item delimiters

also, you should always make sure to reset the text item delimiters to their default value “” after you’re done delimiting your text.

[mdudek]

In case the script fails before the text item delimiters can be reset to default, I always enclose it in a try statement.

try
set AppleScripts text item delimiters to “/”
–process text…
end try
set AppleScripts text item delimiters to " "

I’ve had scripts fail trying to process the text, and when I re-ran them other text operations failed because the the text items delimiters were not set back to the default.

[mark_hunte]

I have not really played with AppleScriptObjC yet,
So I could be missing something here?
But what strikes me when I look here is many people seem to not use the ObjC parts ??

on myAction_(sender)
		
		tell class "NSString" of current application
			set myText to stringWithString_("Wish/I/Could")
		end tell
	 
		set newArray to myText's componentsSeparatedByString_("/")
	
		log newArray
		return
	end myAction_

→
2009-12-02 20:09:04.593 ASOCtest[28795:a0f] (
Wish,
I,
Could
)

And one way of getting individual items in the Array is

set anObject to newArray's objectAtIndex_(2)
		log anObject

→ 2009-12-02 20:12:54.671 ASOCtest[28871:a0f] Could

‘Could’ is returned as object 2 because an Array numbers from 0,1,2,3 and so on.
set anObject to newArray’s objectAtIndex_(0) would return Wish

[Shane_Stanley]

@mark hunte

But what strikes me when I look here is many people seem to not use the ObjC parts ??

I can think of a few reasons for that, the main one being that they’re not familiar with them. There’s also the fact that using them can be fiddly because of the need to coerce the results all the time. And unless there’s some advantage, what’s the point?

[mark_hunte]

It just seemed odd, in an AppleScriptObjC fora.
But your right its new and it will take people time to learn and use them , myself included.
I have been mainly trying to get a handle on Objective C rather than AppleScriptObjC.
The main advantage I am finding is consistency in syntax.
I have not used AppleScriptObjC, So do not know if its the same, in fact that (above) was my first. But I suspect it is.

Craig Williams has just started a part n Documentation which seems one of the key things to learn how to use.

There’s also the fact that using them can be fiddly because of the need to coerce the results all the time.

Do you mean fiddly because of the need to coerce things into an object?

One thing I found lacking in Objective C was methods for controlling other apps.
Scripting Bridge works but there seems a great lack of any good documentation.

[Craig_Williams]

@mark hunte

One thing I found lacking in Objective C was methods for controlling other apps.
Scripting Bridge works but there seems a great lack of any good documentation.

I can’t get the hang of Scripting Bridge and no reason to learn it now. This the one of the reasons I am so excited about AppleScriptObjC. You can be creating a Cocoa app and have the ability to use AppleScript just by adding the AppleScriptObjC framework and making a small change in the main.m file.

For me, I now use the language best suited for the task; AppleScript for sending Apple Events, Objective-C for building the application and Ruby as my goto general scripting language.

I think the greatest value is the flexibility we now have.

[Shane_Stanley]

@mark hunte

Do you mean fiddly because of the need to coerce things into an object?

No, I’m referring to the results returned from ObjC calls. Take your earlier example:

set anObject to newArray's objectAtIndex_(2)

Now that logged fine, but if you want to use it in AS (say to in talking to an app), you have to coerce it to a string (or whatever), because the result is actually returned as a kind of pointer. That has to be done after each call, unless you are passing the value on to another ObjC call.

[mark_hunte]

@Craig Williams

have the ability to use AppleScript just by adding the AppleScriptObjC framework and making a small change in the main.m file.

I think the greatest value is the flexibility we now have.

Ah Thanks Craig, I see what you mean, that would have save me some head ache …

when you say small changes in the main.m file what would they be?

[Craig_Williams]

Here is the main.m file in a normal Cocoa app.

#import <Cocoa/Cocoa.h>

int main(int argc, char *argv[])
{
return NSApplicationMain(argc, (const char **) argv);
}

Here is the main.m file in an AppleScriptObjC app.
You have to add the #import statement and the
NSBundle line to the code above. This and adding
the AppleScriptObjC framework is all it takes to
use AppleScript in a current Cocoa app.

Pretty cool, huh!

#import <Cocoa/Cocoa.h>
#import <AppleScriptObjC/AppleScriptObjC.h>

int main(int argc, char *argv[])
{
[[NSBundle mainBundle] loadAppleScriptObjectiveCScripts];

return NSApplicationMain(argc, (const char **) argv);

}

[Bruce_Phillips]

@mdudek

other text operations failed because the the text items delimiters were not set back to the default.

If those are your scripts, you shouldn’t be relying on a “default” value.

[Shane_Stanley]

@Bruce Phillips

If those are your scripts, you shouldn’t be relying on a “default” value.

That’s true, but an awful lot of scripts end up using text item delimiters without the people who wrote them realising. One very common case is code like:

set x to characters 1 thru 5 of y as text

This makes a list, and then coerces it to a string – which means it uses text item delimiters.

The real fix is to change the script (set x to text 1 thru 5 of y), but this sort of inadvertent use of text item delimiters happens a lot.

Resetting to defaults avoids these sorts of problems. It also helps avoid problems when delimiters are changed in handlers.

[mark_hunte]

@Craig Williams

Here is the main.m file in a normal Cocoa app.

#import <Cocoa/Cocoa.h>

int main(int argc, char *argv[])
{
return NSApplicationMain(argc, (const char **) argv);
}

Here is the main.m file in an AppleScriptObjC app.
You have to add the #import statement and the
NSBundle line to the code above. This and adding
the AppleScriptObjC framework is all it takes to
use AppleScript in a current Cocoa app.

Pretty cool, huh!

#import <Cocoa/Cocoa.h>
#import <AppleScriptObjC/AppleScriptObjC.h>

int main(int argc, char *argv[])
{
[[NSBundle mainBundle] loadAppleScriptObjectiveCScripts];

return NSApplicationMain(argc, (const char **) argv);

}

That is very cool, thanks for pointing that out.
One thing I wanted to ask, I know I need to load the applescript custom class in IB, and connect to it. Which works.
But how do I call it from say a .m file? (I know It is most likely obvious )
Ta.

[Shane_Stanley]

@mark hunte

One thing I wanted to ask, I know I need to load the applescript custom class in IB, and connect to it. Which works.
But how do I call it from say a .m file?

Let’s say your .h file is like this and you’ve made the link in IB:

#import <Cocoa/Cocoa.h>

@class SomeAppAppDelegate;

@interface Extra : NSObject
{
IBOutlet SomeAppAppDelegate *myASClass;
}

-(IBAction)doStuff:(id)sender;

@end

Your .m file might contain something like this:

#import “Extra.h”

@implementation Extra

-(IBAction)doStuff:(id)sender {
[myASClass myTest];
}

@end

[mark_hunte]

Thanks Shane,

I might not have been clear,
If I have a .applescript in the cocoa app. I have no problem connecting it in IB and running it through its actions with for example a button.

But what if I want to call one of its methods from delegate for the app which would be a .m file.

[Shane_Stanley]

@mark hunte

But what if I want to call one of its methods from delegate for the app which would be a .m file.

That’s what the sample does: the line “[myASClass myTest]” in the .m file is calling a handler called myTest() in the AS class SomeAppAppDelegate.

[hhas]

@Craig Williams

I can’t get the hang of Scripting Bridge and no reason to learn it now. This the one of the reasons I am so excited about AppleScriptObjC. You can be creating a Cocoa app and have the ability to use AppleScript just by adding the AppleScriptObjC framework and

FWIW, I’ve just checked an update to objc-appscript into appscript’s Subversion repository, cleaning up various warnings reported by Xcode 3.2’s static analysis tools, providing a better range of build/deployment options (32-bit universal for 10.4+ or 32- and 64-bit with optional GC for 10.5+; for installing into /Library/Frameworks or including in application bundles), and adding a workaround for Snow Leopard’s ‘return ID’ bug.

ObjC appscript’s design is based on Python and Ruby appscript’s, which in turn are designed to work much like AppleScript, so is a much easier transition from AppleScript - plus it’s much less susceptible to application compatibility problems. And you get ASDictionary and ASTranslate to help squeeze as much information and help as possible out of whatever application dictionaries and AppleScript sample code you have to work with.