understanding reference to a document vs its name

Question

Level 1

0 points

understanding reference to a document vs its name

I'm having a hard time understanding how reference to a document works, and where in the AppleScript reference it is explained.

See this simple AppleScript:

tell application "TextEdit"

setMyDocumenttomakenewdocumentwith properties{name:"Name1"}

set text of MyDocument to "SomeText"

set text of MyDocument to text of MyDocument & " with more text"

set name of MyDocument to "Name2"

-- display dialog ("" & name of MyDocument) -- A: throws error

set MyDocument to document "Name2"

display dialog(""&nameofMyDocument)-- B: works fine

endtell

Should I remove the comments at the begining of the line where my comment A is, I would get an error from AppleScript like:

"Can’t make name of document "Name1" of application "TextEdit" into type Unicode text"

However, getting a new reference the "same" document using its new name allows me to display its name in a dialog.

So, I understand that, somehow, when I get a reference to a document object, that reference becomes obsolete if I change its name, as if the name actually defines - to some extent - the uniqueness of the object (although TextEdit can have more than one document named "Name2" at the same time, as is shown by the result of running the above script a few times without window cleaning).

I must say this behavior is somewhat a surprise to me, as I thought that, having a "pointer" to the object (I will avoid the term reference here), changing the value of a property of the object wouldn't render my pointer invalid. But no; it seems as if my pointer/variable is re-evaluated when used, and that this evaluation is done using the name property as if it was its unique key. Or is it something else?

What I would like to know is:

How do I know what are the properties that "uniquely" defines an object (and which, if I change them, will screw up the validity of my variables)? Is the name property the only one, or are there other ones? Whenever I see a name property in a class, should I understand it is a "unique key", or are there classes where the name property can be changed without making any of the above problem?
How do I know which property is used by default to evaluate where a variable points to?
Is there any way to make a variable point to such an object without risking to lose it even when an "unique key" property is modified? I've played a bit with the "a reference to" operator with no success (although I might not have used it right).
What part of the AppleScript reference explains this so my AppleScript-newbie/former-java-programmer brain can understand the logic behind this. I kinda understand what's happening, though I'd like to clearly be explained why it works that way.

Thanking in advance you, seasonned AP coders, for sharing your knowledge...

Posted on Sep 9, 2013 9:59 PM

Reply

Answer 1

Best reply

twtwtw

Level 5

4,936 points

Sep 9, 2013 11:35 PM in response to Fredeni

1.

The unique identifier of an applescript object can vary from object to object and application to application. Name and id are commonly used for unique identifiers, index is sometimes used, and some applications define their own odd unique referents. Plus, an object can have more than one unique identifier. In fact, you can objects with no public unique identifiers: e.g. 'word' objects, which can only be referenced by relative or absolute position in a string. See the discussions in applescript reference forms.

So no, name properties are not always unique, though usually either the name or id property will be unique.

2.

As a rule, unique properties will be listed as read only (r/o) which means they can only be set at the time the object is made. Sometimes you have to hunt for them, though. For instance, document objects in Text Edit seem not to have any unique identifier until you notice that window objects have a unique id property and each window object has one and only one document object. So, you can uniquely specify a document using something like document of window id xxxxx.

Note also that applescript can be annoyingly inconsistent. Sometimes you'll write a reference that looks correct and even compiles and it still won't work. It depends on how thoroughly the developer fleshed out the core applescript routines.

3.

If you're going to change a unique property, step up to the object's container and find another unique reference that (temporarily) won't change. For example, if you want to change a file's name, find a reference to the file within its folder (e.g. third file of folder x). Of course, you can always kite it as you did above (change the name and then reference it as though it were a new object with the new name).

4.

read the object specifiers section of the applescript language guide; should get you oriented.

Reply

Answer 2

Fredeni Author

Level 1

0 points

Sep 10, 2013 6:51 AM in response to twtwtw

Thank you twtwtw,

Going back to the Object Specifiers section, and then back to the Declaring Variables section, I realize that some key information was right there in front of me, hidden by my assumptions of how the language should work:

"An object specifier is fully evaluated (or resolved) only when a script is run."

"Applications typically return object specifiers in response to commands."

"You create an object specifier every time your script uses a phrase that describes the path to an object or property.""

"You can assign [to a variable] a simple value, an expression, or an object specifier—expressions are evaluated and object specifiers are resolved to obtain the value to assign."

I guess that's part of the learning process to understand that a JavaScript variable is not the same as a C or Java variable. I wished there was more emphasis put on the impacts of changing the value of properties that are used/can be used as an absolute object specifier. Although I admit there might be enough already and I simply missed it reading in diagonal.

Thank you again for taking the time to write such a comprehensive reply.

Reply

Answer 3

twtwtw

Level 5

4,936 points

Sep 10, 2013 10:05 AM in response to Fredeni

My pleasure. Applescript documentation is elliptical at best, so learning the language is a lot more experimentation-oriented than you'll find with other languages. There are reasons for this going back to applescript's roots [insert long historical monograph here], but you get used to it. 😀

Reply