Way back when, I had a way to do that using script objects and do script.
In short you would get the text strings you want for the record labels, build them into a script variable, run that variable as a script object, and return the created record. It's clunky, but IIRC you drop it into a handler and put that in a library and
it worked every time with a single handler call.
Another handler would go the opposite way, returning record labels as text string.
This was years ago, and on first look I was unable to find it.
I needed this in dealing with a quark script that would print using various printer description files. Those would be loaded at runtime and the information in the records, including record labels, would change from on PD file to the next. Turns out there
are many ways of referring to page size.
This script would work on all of the macs in our office on first run without having to rescript the records for the print command. (We dropped Quark for ID, so it's not used anymore.)
On Tue, 04 Aug 2015 23:40:30 +0100, has
<email@hidden> wrote:
In AppleScript? No. An AppleScript record is a fixed collection of
properties, not an arbitrary collection of key-value pairs (associative
list, hash, dictionary, etc [1]). In other languages? Sure, since those
generally map AE records to dictionaries, it's absolutely trivial; but
then you need an Apple event bridge that doesn't crap its pants at the
sight of InDesign (so you can forget about Scripting Bridge and
_javascript_ for Automation in other words[2]).
It's really too bad there isn't some way to do that. It would add so much flexibility to the language.
If InDesign can't handle your 'set properties of <whatever> to <record>'
command correctly, then as you say you'll need to set each property
individually. While you can't iterate over an AppleScript record, you
_can_ concatenate it with a second record, allowing you to add any
'missing' properties:
set change grep preferences to nothing
set changeProps to changeProps & (properties of change grep
preferences)
InD pukes on that, probably because some readonly props are included in the list. Since I know there are a limited number of props I need to set in this function, I ended up sending them as parameters and setting them individually.
[3] In practice, ID does appear to be extremely sensitive to the precise
order in which certain properties are set, e.g. if the script tries to
set the numbering format before the numbering list type, it throws a
'Cannot set bullets or numbering properties in Find/Change if the list
type is none or not set' error. My guess is that when you do 'set
properties of change grep preferences to changeProps', ID is stupidly
applying your new settings in the order in which they appear in your AE
record (which is totally arbitrary) instead of the order ID _needs_ them
to be set, with any failed assignments being silently ignored instead of
reported as errors. Such implicit, invisible order-sensitivity should
not exist - clearly the interface design wasn't thought through with
adequate rigor, or they'd have grouped such dependent properties into
classes/records of their own - but the entire ID dictionary is a giant
sprawling mess like this, so I doubt much can be done about it now.
This was one thing we were mindful of when we were writing Creator back when I was at MultiAd. If any class had property dependencies like this, we processed them first and added those props to a set that was then passed along to the regular prop setting
code so it could ignore setting those props again. It added some complexity to the code, but made for a very pleasurable scripting experience for the user.
With this in mind, a quick-n-dirty workaround could be to put your 'set
properties...to changeProps' command in a 'repeat N times' loop, so that
it gets sent enough times for all the given values to eventually stick.
The scripts need to be as fast as possible, so I'd shy away from that sort of thing here. (Even though it might be in the millisecond range to send that command 3 or 4 times, it still feels slow to my human brain.:)
Sent from iCloud, so sorry for the crappy formatting
|