• 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: Fri, 22 Oct 2010 09:41:12 -0400

On Oct 21, 2010, at 9:27 PM, Deivy Petrescu wrote:

>
> On Oct 21, 2010, at 9:18 PM, Deivy Petrescu wrote:
>
>>
>> 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"
>>
>>
>
>
> Ooops. I didn't realize that the if is going to be always true.
>
> May be changing it to:
>
> if (refRecord as string = "named") then display dialog "named"
> That is, coerce the key form to string.
>


Apologies for not reading the whole email.
has solution is certainly much better than what propose here.
Because the problem happens at compilation, avoid it.

Here is a suggestion which uses hacks as well


<script>
set Zscript to "tell application \"System Events\" to set procRef to process \"Finder\" \r\tset refRecord to get  («class from»  of (procRef as record))\r\rreturn refRecord"
run script Zscript
try
	set k to (result as string)
on error e
	set k to text 12 thru -19 of e ---this hacks is set to correctly get what you want as string.
end try
</script>

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

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

  • Prev by Date: Re: Scripting and Back to Mac
  • Next by Date: Re: [ANN] New book on AppleScriptObjC
  • 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