• 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: A bit more UI capabilities? (was: Re : on blocking target applications' GUIs)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A bit more UI capabilities? (was: Re : on blocking target applications' GUIs)


  • Subject: Re: A bit more UI capabilities? (was: Re : on blocking target applications' GUIs)
  • From: Axel Luttgens <email@hidden>
  • Date: Sun, 21 Dec 2008 05:05:46 +0100

Le 20 déc. 08 à 02:38, Chris Page a écrit :

On Dec 20, 2008, at 12:48 AM, Axel Luttgens wrote:

For example, should one need more than three choices (hence, more than three buttons), it is required to nest multiple dialogs ... or to devise some more or less clever (naughty?) tricks with the help of "choose from list".

That is exactly what ‘choose from list’ is for: choosing from several items. Can you provide an example where using a list would be "naughty"?

Using it as a collection of pseudo-buttons, as described hereafter.


Do you mean you need nested controls? Like:

 () Choice A
    [] an option for A
    [] another option for A
 () Choice B
    [] an option for B
    [] another option for B

() is a radio button, [] is a checkbox.

Wow, that would be luxurious. :-) But this sure would be overlapping with Studio...

No, I was considering the rather frequent case of needing to ask the user which action to undertake during a script's execution.
One often end with something like this:


try
set {T, B} to {text returned, button returned} of (display dialog "Please enter a string:" default answer "example" buttons {"Cancel", "Uppercase", "Other..."})
if B is "Uppercase" then
set R to Uppercase(T)
else
set {T, B} to {text returned, button returned} of (display dialog "Please enter a string:" default answer T buttons {"Cancel", "Lowercase", "Capitalize"})
if B is "Lowercase" then
set R to Lowercase(T)
else
set R to Capitalize(T)
end if
end if
on error
set R to false
end try


This may impose up to two steps to the user; and anyway, this is not really satisfactory, as the user hasn't the opportunity to review the previous available choices anymore once he has clicked the "Other..." button.

One may thus be tempted to make use of "choose from list":

try
set T to text returned of (display dialog "Please enter a string to act upon:" default answer "example" buttons {"Cancel", "OK"})
set B to first item of (choose from list {"Uppercase", "Lowercase", "Capitalize"} with prompt "What do you want to do with \"" & T & "\"?")
if B is "Uppercase" then
set R to Uppercase(T)
else if B is "Lowercase" then
set R to Lowercase(T)
else
set R to Capitalize(T)
end if
on error
set R to false
end try


Again, this imposes two steps to the user; moreover, this may appear slightly disturbing, as an interface intended for the selection of items in a list is used as a dialog with 5 buttons, 3 of them being fake ones.

On the other hand, shouldn't we be restricted to three buttons with "display dialog" anymore, things would be much simpler, for both the user and the scripter:

try
set {T, B} to {text returned, button returned} of (display dialog "Please enter a string:" default answer "example" buttons {"Cancel", "Uppercase", "Lowercase", "Capitalize"})
if B is "Uppercase" then
set R to Uppercase(T)
else if B is "Lowercase" then
set R to Lowercase(T)
else
set R to Capitalize(T)
end if
on error
set R to false
end try


This is not to say that "display dialog" should allow for an infinity of buttons... but three buttons only often appear too limiting.


They are also a bit too limited in their scope. For example, native progress bars and keyboard sensing would certainly delight more than one scripter.

Perhaps would it be a good idea to integrate such capabilities into AppleScript, while preserving its current KISS approach for such matters (I mean, no need to incorporate a full-fledged say, AppleScript-Studio into the language, just small incremental changes such as allowing more than three buttons in a dialog).

This is why AppleScript Studio was created. This enables people to use Interface Builder and Cocoa without us having to do a lot of work to duplicate that functionality. It was created so that we wouldn't have to turn ‘display dialog’ into something like Dialog Director.


Obviously, finding the right place to draw the line between using a plain AppleScript and using Studio is challenging.

Agreed. ;-)

Perhaps a reasoning like this one may help to draw that line: a computer has a disk, a screen, a loudspeaker, a keyboard, and runs programs over time. AppleScript (with its standard additions) can read and write files, display dialogs on the screen, pronounce some text and emit beeps; but it can't read the keyboard nor symbolize the flow of the time.

Axel _______________________________________________
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: 
 >A bit more UI capabilities? (was: Re : on blocking target applications' GUIs) (From: Axel Luttgens <email@hidden>)
 >Re: A bit more UI capabilities? (was: Re : on blocking target applications' GUIs) (From: Chris Page <email@hidden>)

  • Prev by Date: ‘run script’ best practices (was Application Script Menus)
  • Next by Date: Re: Tell Block With Variable
  • Previous by thread: Re: A bit more UI capabilities? (was: Re : on blocking target applications' GUIs)
  • Next by thread: Re: AppleScript and programmers (was: Re: on neophytes vs perfectionists)
  • Index(es):
    • Date
    • Thread