System Events understands TextEdit references?

While crafting a handler to convert ‘anything’ into an HFS path string I discovered this:

tell application id "com.apple.TextEdit" to set f to document 1
tell application id "sevs" to path of f 
--> POSIX path

The Event Log shows NO involvement of System Events.
What the…??

A SE item has properties path AND POSIX path, but path returns a POSIX path here, so that seems to confirm SE is not involved.
It smells a bit like ‘autocorrect’…

[10.11.6]

Hi.

In your script, ‘f’ is a TextEdit reference to a TextEdit document, so TextEdit is invoked to get the document’s ‘path’. System Events plays no part in the process. System Events only knows the paths of its own ‘disk item’ subclasses, and these are returned as HFS paths.

tell application id "com.apple.TextEdit" to set f to path of document 1
--> POSIX path

tell application id "sevs" to path of file f
--> HFS path

tell application id "sevs" to POSIX path of file f
--> POSIX path

It is autocorrect, made by smart AppleScript. Finding that the argument is not file object, but document object, AppleScript resolves path property of this document. So, your code is equivalent to that:


tell application id "com.apple.TextEdit" to set f to document 1
path of f
--> POSIX path

To get HFS path, you should create alias file reference, which is most common file referencing format for different apps:


tell application id "com.apple.TextEdit" to set f to document 1
set f to POSIX file (path of f) as alias
tell application id "sevs" to path of f
--> HFS path

OR, better:


tell application id "com.apple.TextEdit" to set f to document 1
set f to POSIX file (path of f) as text
--> HFS path

So, the answer is this: System Events doesn’t understand TextEdit document references.

@KniazidisR Please run your code before posting it.

All your code examples throw errors.

Is assumed that you have opened one real TextEdit document before running the scripts. I double-checked: all my 3 code snippets works fine.

Of course but in any case it’s very bad practice to use terminology of an application outside of its application tell block.

Script Editor might be polite enough to resolve the path property outside of a TextEdit tell block, however Script Debugger is not and throws an error.

KniazidisR’s examples all work here provided that the front document in TextEdit has been saved. However, he should check that he’s not simply repeating what someone else (me in this case) posted an hour and a quarter earlier. :wink:

On my machine (10.14.6) Script Debugger 7.0.8 throws an error (which is the expected behavior).

You cannot rely on the correct terminology resolution outside of the tell block of its application.

The TextEdit document is saved and reopened.

Strange. They work on my machine. Identical software and versions. :confused:

I figured out why. In my scripts the standard AppleScriptObjC use lines are present by default.

I agree that it is better to get all the properties inside the tell block. But here the OP used this very “bad” approach. Therefore, I decided to clarify the situation without changing the structure of the code. Also, I do not consider the tests I have given to be a repeat.

Aha. A classic complaint about a script not working when it’s not what was posted. :wink:

@ KniazidisR:
I’m well aware of the points you made in your first reply, thank you.

There is no “bad approach”. I posted two lines of code to illustrate an observation I made, that’s all. Those lines do not appear in the handler I wrote.

Anyway, as I now understand it I can reduce the 2nd line to just “path of f”, and I will get a result, provided the item has a ‘path’ property’.
Finder items don’t have it, but you can convert those references directly to text.