Thanks for your concern and kindly help.
Yes, I received all messages related and I've been working on some
other scripts for a while.
I think the solution of UI is a good idea. I haven't used it yet but I
believe it will work.
Sorry my english is not enough to make it clear. In fact I found
that KIND in dictionary is r/o but I haven't found a way to use
AppleScript to make changes like shown in here:
<http://www.modulos.net/picture1.pdf>.
Note that what I call "track name" was changed from "Sound Track 1"
to "portugues" using QTP's properties window. This is what I need.
Applescript let me change the TRACK NAME and cause a change in
annotation "name " of the track - note "Sound Track 2" with
annotation name "espanhol". What I don't need.
As a newbie, I could not found (yet) a property in QT dictionary to
solve this. I'll keep looking.
Ok, I think I might call this a bug... I know what you're talking
about now.
If you pull up Movie Properties, and look at a track, there's a
"Name" column. When you get the name of that track using AppleScript,
it returns the value in the name column. If you edit the value in the
name column using Quicktime Player, AppleScript will return the new
edited name.
However, if you "set" the "name" of that track using AppleScript, it
adds an annotation of type "Name" with the value you set, to the
track, leaving the original value in the name column of the
properties alone. Now, if you get the name of the track using
AppleScript, it returns the value of the Annotation, not the value in
the column.
At best this is confusing and inconsistent, but it looks like a bug
to me.
I just submitted a bugreport to Apple, assigned number 4130968. It's
described in more detail there.
Did you get this message? I'm not sure if the list is working this
week or not, it's hard to tell as there have been very few messages
except mine that I've seen.
Anyway, I went to a lot of trouble to test and file this bug so I'm
just hoping you saw it; if you're still looking for a workaround for
doing this with AppleScript the only solution for now that I can see
would be to give it a try with UI Scripting - you'd basically be
simulating a user editing these properties in Quicktime Player by
hand, so it should work just like it does manually, avoiding the
AppleScript-related bug we saw (not saying it's an AppleScript bug,
it's probably a Quicktime Player bug, but it only comes up when
working through AppleScript).
