Re: Passing app property names
Re: Passing app property names
- Subject: Re: Passing app property names
- From: Steve Mills <email@hidden>
- Date: Wed, 05 Aug 2015 18:00:51 +0000 (GMT)
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden