New versions of Dialog Toolkit

AppleScript Dialog Toolkit
#1

I’m about to release two new versions of Dialog Toolkit, and I’m hoping for some feedback.

The first version, 2.0.3, is a simple update: it fixes one small bug, it works around a bug in the High Sierra betas that I fear will make it into the release version, and includes a bit of code tidying/refactoring.

The second version will actually be a separate library, called Dialog Toolkit Plus, and will have several new features based on feedback I’ve received. It’s a separate library so that existing scripts don’t break, however it should be largely backwards compatible — so updating existing scripts should consist of no more than changing the use statement from Dialog Toolkit to Dialog Toolkit Plus.

There are two major changes in Dialog Toolkit Plus:

  • Many parameters are now optional. This will simplify code, and allows me to add new parameters without breaking existing scripts. The downside to this is that it means it cannot be used under macOS 10.9. (That’s why it’s a separate library.)

  • It introduces an extra command, display enhanced window, which can be used instead of display enhanced alert. As the name implies, this lets you build a dialog that is not based on an alert. This means I can fulfil several requests people have made.

The enhanced window still works with the concept of an accessory view, however in this case there is no icon on the left, and no bold alert text and message above it. Instead the accessory view is full-width (allowing for margins at the sides and top), with a row of buttons underneath.

The first step to building an enhanced window is to create the buttons, using the create buttons command. You pass a list of button names, and optionally designate which are the cancel and default buttons. You can also optionally provide a list of keyboard shortcuts to be assigned to the buttons. The command will return the list of button objects to pass to the display enhanced window command, plus the minimum width of accessory view that will be required to match the space taken by the buttons.

You then build up the accessory view controls as before. The display enhanced window command takes the same parameters as the alert (minus those for the main text, message and suppression checkbox), plus a parameter for the buttons, as well as optional parameters to set the initial active field, the initial position on screen, and whether the designated cancel button should be aligned left.

The other commands have also been modified, mostly by making various parameters optional. But there are some other changes too:

  • Labels have parameters for control size (ie, type size: regular, small and mini) and whether to use bold type.

  • The ‘max width for labels’ command also supports control size and bold type parameters.

  • Matrixes and popups, with or without labels, have a parameter for setting the item initially showing/checked.

There’s also a new max depth for label command.

So I’m looking for:

  • People willing to test the new Dialog Toolkit with existing scripts.

  • People willing to try Dialog Toolkit Plus.

  • Feedback on any other feature requests. Speak soon, or forever hold your peace.

I’ll add links here in the next day or so.

3 Likes
#2

Sounds good!

I’m willing.

Any chance of at least a list control? (as you know, I’d really like a table control).

Thanks, Shane.

#3

Not really – it’s not something that can be done in a practical amount of code.

What’s the problem with a matrix?

#4

I’m in!

It’s the least we can do to thank you for your selfless assistance.

:wink:

#5

Just a note on requests: time is short, so please try to stick to things that would be generally useful, rather than solutions to relatively rare problems. There are still lots of limitations, but it’s also starting to get rather big.

#6

I’ll amplify Shane’s response based on my experience with trying to support tables in my ill fated FaceSpan project.

Once you go beyond a table displaying a list of strings, the complexity goes way up. First, there are multiple columns. Then, multiple data types (ints, reals, booleans, etc.) and multiple renditions of these values. Then people want to control over how they are formatted (decimal points, comma separators, etc). Then there are images. And I’ve not even touched on editing values within a table. On and on it goes.

#7

Seems like Shane overcame this difficulty in his Myriad Tables lib.

But I get your point. I wonder, if you were to keep it simple and just display the data using the data type in the list (all items in a list the same type), would that make it easier? No editing, just an enhanced choose from list.

#8

I need to investigate more.

Any changes to matrix in the new version?
So, are you saying that I can display a list of items for the user to choose using matrix? I don’t see how that would work for a long (> 20) list of items.

image
image.png811×420 82.1 KB

#9

But not using ASObjC code. Even restricting it to a single list, it would be daunting.

#10

No.

It clearly wouldn’t — that’s what popups for.

The fundamental issues are that (a) tables are too complex, and (b) there are mechanisms for choosing (a single item) from a list already.

#11

Shane, these are my first comments.
They all rely to the display enhanced window command.

  • Is it on purpose that the default button does not respond when hitting the return key ?

  • There’s no visual response from the buttons when triggered by shortcut. I think we need it, for other reason than cosmetic…

  • The same size for all buttons will be ugly with something like {“Cancel”,“A very long button title”, “A short one”, “OK”}.

  • Could the first and last button be the cancel and default buttons by default?

  • Maybe you could add examples for unitial sates of controls in the Complex Sample?

  • Is it possible (in the long term) to add a combo box facility to display and return values in user defined units (mm, pts, picas…).

#12

No, that’s a bug — a fix is coming.

I agree — I’m not sure why it’s not happening.

I can see pros and cons. Maybe I need an option…

No — that was a point of complaint about the previous version. People mean to type a return in a text field, and end the dialog by default. Users want some way to stop accidental closure.

Not in ASObjC.

#13

Can it be because we need a sort of delay before the window is dismissed?

I understand that. I just meant: make those parameters optional.

I suspected that a little…

#14

Here’s a new version.

  • The default button now properly responds to return.

  • Buttons highlight properly when triggered by shortcuts.

  • There’s a new optional parameter for the create buttons command, equal widths.

  • There’s a new optional parameter for the field commands, accepts linebreak and tab, so you can designate that a field will accept tab/return/enter.

See newer version below

#15

Display Enhanced Window:

  • There’s a beep when clicking on any button.
  • When cancelling the dialog, the variable buttonName is not defined.
  • Active field should be a parameter for the field creation to avoid error when using a copy of a script to create a new dialog.
  • It would be good to check that the button keys’s count is the same as the create buttons.
  • Can you add the abbility to set the default button index to a negative value (i.e. starting from the last)?
#16

Tell me if I’m wrong but I feel there’s an inconsistency with the initial values: we set them with indexes and they are returned as contents.
It would be easier to use (after the colorPopup variable is declared as a persistent property):

 set {colorPopup, popupLabel, theTop} to create labeled popup {"Red", "Green", "Blue"} bottom (theTop + 8) popup width 100 max width accViewWidth label text "Job is for:" popup left 70 popup default colorPopup
#17

It’s a good argument, but I don’t follow your code — you’re using the same variable for the popup and for the default entry.

So I think I’ll change both popup default and index default to initial choice, and have it accept either the index or the text. And do something similar with the default/cancel buttons. Does that make sense?

#18

Sounds perfect!

Better than words, this is one of the scripts I use for testing:

 ##THIS CODE IS ONLY FOR TESTING and won't work if you hit the cancel button because now it returns the error -128
use AppleScript version "2.4"
use scripting additions
use script "Dialog Toolkit Plus" version "1.0"

property colorPopup : 1
property colorPopupList : {"Red", "Green", "Blue"}

set accViewWidth to 400
set {theButtons, minWidth} to create buttons {"Cancel", "This sample shows how to build a reasonably complex dialog", "OK"} default index 3 cancel index 1 -- with equal widths
if minWidth > accViewWidth then set accViewWidth to minWidth -- make sure buttons fit
set {colorPopup, popupLabel, theTop} to create labeled popup colorPopupList bottom 16 popup width 100 max width accViewWidth label text "Job is for:" popup left 70 popup default colorPopup
set allControls to {colorPopup, popupLabel}
set {buttonName, controlsResults} to display enhanced window "Complex sample" acc view width accViewWidth acc view height theTop acc view controls allControls button list theButtons with align cancel button
set colorPopup to (item 1 of controlsResults)

-- this will be useless with the next version of DTplus
if colorPopup = "Red" then
	set colorPopup to 1
else if colorPopup = "Green" then
	set colorPopup to 2
else
	set colorPopup to 3
end if
#19

OK, now I understand.

#20

  • The create buttons command now has cancel button and default button parameters, both of which take either the name or index.

  • The matrix and popup commands now have an initial choice parameter, which takes a name or index.

See newer version below.