• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Feature request to solve a problematic AppleScript behavior with raw Apple Event codes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feature request to solve a problematic AppleScript behavior with raw Apple Event codes


  • Subject: Re: Feature request to solve a problematic AppleScript behavior with raw Apple Event codes
  • From: Deivy Petrescu <email@hidden>
  • Date: Thu, 21 Oct 2010 21:18:15 -0400

On Oct 21, 2010, at 5:54 PM, Scott Babcock wrote:

> I have a request for a feature that would solve a problematic AppleScript behavior - conversion of raw Apple Event codes to their "friendly" equivalents and rendering the affected code non-compile-able.
>
> I ran into a situation in which I needed to branch based on the form of a specified object reference (named/index/id). Getting the reference form is obscure but relatively easy (coerce the reference to a record and grab the <<class form>> property). From there, I need to compare the form to a constant (e.g. - <<constant ****name>>).
>
>>>> BEGIN
>
>    set procRef to propess "Finder" of application "System Events"
>    set refRecord to procRef as record
>    if ((<<class form>> of refRecord) is <<constant ****name>>) then display dialog "named"
>
> <<< END
>
> The difficulty in this scenario is that AppleScript is too "helpful". When it compiles <<constant ****name>>, this raw code is converted to the text "named".
>
>>>> BEGIN
>
>    set procRef to process "Finder" of application "System Events"
>    set refRecord to procRef as record
>
>    if ((<<class form>> of refRecord) is named) then display dialog "named" -- compilation has rendered this line non-compile-able
>
> <<< END
>
> The underlying code will be correct, but the source can no longer be compiled - it's syntactically incorrect. There are a couple of ugly ways to deal with this using strings:
>
>>>> BEGIN
>
>    property byName : run script "<<constant ****name>>" -- hack #1
>
>    set procRef to propess "Finder" of application "System Events"
>    set refRecord to procRef as record
>
>    if ((<<class form>> of refRecord) is my byName) then display dialog "named (hack #1)"
>    if (((<<class form>> of refRecord) as text) is "named") then display dialog "named (hack #2)"
>
> <<< END
>
> These hacks do the trick, but there's a property in the reference record that can't be dealt with this way - <<class from>>. This property contains a reference to the object's parent - in this case, System Events. The raw Apple Event <<class from>> gets converted to the text "from", rendering the code non-compile-able. There's only one way I know of to deal with this issue - coerce the record to a list and grab the last item. This isn't a great solution, because it relies on a fixed ordering of the values from an unordered set. It would be far better to have some way to prevent AppleScript from performing the raw-to-friendly conversion.
>
> The solution would be to provide a way for the scripter to inform the compiler that a raw code should remain "uncooked" - perhaps something simple like wrapping the raw code with backtick (`) characters.
>
>>>> BEGIN
>
>    set leaveMeRaw to `<<constant ****name>>`
>    set _parent_ to `<<class from>>` of refRecord
>
> <<< END



Will this do?


tell application "System Events" to set procRef to process "Finder" of application "System Events"
set refRecord to get («class form» of (procRef as record))
if (refRecord = result) then display dialog "named"







Deivy Petrescu
email@hidden



 _______________________________________________
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

  • Follow-Ups:
    • Re: Feature request to solve a problematic AppleScript behavior with raw Apple Event codes
      • From: Deivy Petrescu <email@hidden>
References: 
 >Feature request to solve a problematic AppleScript behavior with raw Apple Event codes (From: Scott Babcock <email@hidden>)

  • Prev by Date: Re: Feature request to solve a problematic AppleScript behavior with raw Apple Event codes
  • Next by Date: Re: Feature request to solve a problematic AppleScript behavior with raw Apple Event codes
  • Previous by thread: Re: Feature request to solve a problematic AppleScript behavior with raw Apple Event codes
  • Next by thread: Re: Feature request to solve a problematic AppleScript behavior with raw Apple Event codes
  • Index(es):
    • Date
    • Thread