• 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: Picking your brains about dates and times
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Picking your brains about dates and times


  • Subject: Re: Picking your brains about dates and times
  • From: Andrew Oliver <email@hidden>
  • Date: Thu, 04 Feb 2016 19:56:52 -0800

On Feb 4, 2016, at 2:17 PM, Stan Cleveland <email@hidden> wrote:

First, let me make clear what I mean (and don’t mean) when I say an app has "good AppleScript support." Primarily, it means that most, if not all, of the application's functionality is exposed via AS terminology. It does NOT mean that using it, learning it, or understanding it is EASY. On the other hand, I only consider apps with little or none of their functionality available via AS to be worthy of your "pigsty scrapings" and "Satan’s vomit" analogies.


I knew I should have bitten my tongue before writing… Oh well… :)

In any case, I stand by my comment. I’m not arguing that Excel has AppleScript functionality, and it’s arguable that *any* scriptability beats *none* (are you listening, Apple?), however, as far as Excel following the AppleScript Terminology Guidelines (1), it’s awful. It’s pretty clear that Excel’s scripting implementation is a hybrid (bastard child?) _vbscript_/AppleScript and it’s is very hard to get to grips with.

Maybe we can just agree that Excel has good *scripting* capability, just not AppleScript (maybe I’m a purist?).

There are many examples where Excel’s scripting differs greatly from ‘pure’ AppleScript, and in ways that overly complicate the process for users. It might make sense from a programming implementation standpoint, but as a user it is highly counter-intuitive. Take, for example:


1: get

Why are there THIRTY SIX ‘get’ commands that set specific properties? 

get address
get address local
get axis
get border
get border
get border
get chart element
get clipboard formats
get combobox item
get count of combobox items
get custom color
get custom list contents
get custom list num
get dialog
get end
get file converters
get filemaker criteria
get has axis
get international
get list item
get offset
get open filename
get pivot data
get pivot table data
get previous selections
get registered functions
get replacement list
get resize
get rotated text bounds
get save as filename
get subtotals
get values
get visible fields
get webpage font
get xml value


Why are these not all implemented via a simple single ‘get’ command (which also exists) with an appropriate property and object identifier? More to the point, how is a user supposed to know whether to use regular ‘get’ with an object and property, or this specific command?

For the sake of brevity, I’ll omit listing the 14 ‘set’ commands that should all be implemented via a single ‘set’ with a object/property specifier. I’ll also omit the 21 different “clear…’ commands and the 14 ‘add…’ commands; the 11 ‘copy…’ commands, 11 ‘clear…’ commands; and the 10 different 'save…’ commands.

2: duplicate commands

Pop Quiz: What’s the difference between these four commands:


check spelling
check spelling
check spelling
check spelling


Answer: They are each implemented in different suites (the Microsoft Excel suite, the Drawing Suite, the Table Suite and the Chart Suite). Why? Why not one implementation that passes a target object and takes it from there? They all take the exact same set of optional parameters.


Similar BS… oops, I mean issues exist with the three different ‘print out’ commands (which is somehow different from the ‘print’ command); the two ‘refresh’ commands (which are different from the ‘refresh all’ command); the three ‘activate object’ commands; the three ‘bring to front’ commands (along with corresponding three ’sent to back’); the three ‘clear contents’ commands, the four ‘copy picture’ commands… the list goes on.

In short, the dictionary is a mess. I agree that with time and practice (and practice, and hundreds of dollars in the swear jar, and more practice) you can probably get Excel to do what you want via it’s scripting interface, but to call it a good implementation of AppleScript is an insult to AppleScript.

Andrew
:)

1) https://developer.apple.com/library/mac/technotes/tn2002/tn2106.html
 _______________________________________________
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: 
 >Picking your brains about dates and times (From: "Stockly, Ed" <email@hidden>)
 >Re: Picking your brains about dates and times (From: "S. J. Cunningham" <email@hidden>)
 >Re: Picking your brains about dates and times (From: Andrew Oliver <email@hidden>)

  • Prev by Date: Re: Picking your brains about dates and times
  • Next by Date: Re: Picking your brains about dates and times
  • Previous by thread: Re: Picking your brains about dates and times
  • Next by thread: Re: Picking your brains about dates and times
  • Index(es):
    • Date
    • Thread