New versions of Dialog Toolkit

[Garry]

Sorry, should’ve seen that. Many thanks.

[ShaneStanley]

So the release version is now available here:

https://www.macosxautomation.com/applescript/apps/Script_Libs.html#DialogToolkit

Thanks for all the feedback!

[ShaneStanley]

I’ve just released a Dialog Toolkit Plus 1.0.1, which fixes a bug when setting the initially selected item in a matrix. The link above will take you to it.

[ShaneStanley]

I’m just about to release version 1.1.0 of Dialog Toolkit Plus. It’s mainly a large refactoring to deal with threading issues that have become more important with Mojave, but there are also a couple of other changes, including a new secure field for stuff like password entry. It also addresses an issue with cancel/default buttons that may reverse them in some scripts, unfortunately.

[ShaneStanley]

Version 1.1.0 is now out, available here:

https://www.macosxautomation.com/applescript/apps/Script_Libs.html

[ShaneStanley]

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

Coming back to this, the last few messages in this thread:

Myriad Tables Questions

Actually, @estockly, a better approach would be to use Display Dialog Toolkit itself to build the controls. Then you just need your own handler to build the accessory view, which you then pass on. So here’s such a script. The first part is from Align sample.scpt, which builds a dialog of various widgets. But once the script has created the controls, instead of showing them in a DDT window, it adds them to an accessory view and passes that to some of your Myriad Tables code. This is a lot simpl…

offer a potential solution by combining Myriad Tables with Dialog Toolkit Plus, so the former provides the table and code from the latter provides the other controls.

[JMichaelTX (Jim Underwood)]

offer a potential solution [for a list control] by combining Myriad Tables with Dialog Toolkit Plus, so the former provides the table and code from the latter provides the other controls.

That’s really great Shane!
Thanks for your great Libs, and for remembering my question.

[ShaneStanley]

Thanks for your great Libs, and for remembering my question

FWIW, I did spend a bit of time trying to include a list view in Display Dialog Plus, but doing it in code alone proved even harder than I thought. I think the combo provides a better solution, though, because there are far fewer restrictions on table type.

[Garry]

Shane, I’ve encountered a weird problem.

My app has a dialog created with the Dialog Toolkit Plus. I have an automator service which runs in web browsers. Running the service switches from the browser to my app (by making my app frontmost).

It works fine normally. But, if the browser is in full screen, my app’s dialog “blinks”.

I don’t know how to describe it better but it’s as if the dialog is being displayed twice quickly – but only if the switch is from a browser (or any application) in full screen mode. I get the same if I manually switch from an app in full screen to my app (ie. using command-tab).

This also seems to affect GUI scripting code in the service (which pastes text into my app’s dialog) – it doesn’t run after my app is made front most.

This is happening in macOS 10.13 and 10.14 (I can’t test any earlier OSs).

Could there be something in my implementation of Dialog Toolkit Plus v1.1.0 that’s the cause ?

[ShaneStanley]

I don’t see it here, although the service fails with a message Can't ... because <app name> is not showing the main dialog. I suspect switching from full-screen to no-full-screen is just something GUI scripting needs to take extra care for.

I don’t see any simple solution…

[Garry]

Many thanks.

I’ve often had that error but not for a while – perhaps because I’ve granted Safari assistive access or have rewritten my service – I’ve found it hard to tell why such errors appear then not appear.

The blinking might be a symptom but my main problem is I need to set the value in a text box of my app.

I’ve done more work on the service. This code switches from Safari to my app without errors but, doesn’t set the value in the text box if it starts with Safari in full screen mode. When Safari is not in full screen, it does set the value.

 	tell application "System Events"
		set value of text field 1 of window of process MyAppName to "Just testing"
		delay 1
		tell process MyAppName
			set visible to true   --  in case being hidden is a factor
			set frontmost to true
		end tell
	end tell

I set the value in the text box before switching as it didn’t work when done after. Maybe either way will work if I understand the underlying problem.

It’s been very frustrating as sometimes it works and I can’t figure out what was different. Anyway, I doubt it’s the Toolkit so, I’ll look further afield.

Cheers.

[Garry]

I might have a solution/kludge – it’s just a crude exiting from full screen before switching and GUI scripting:

	tell application "System Events"
		tell process Safari
			tell front window
				set value of attribute "AXFullScreen" to false
			end tell
		end tell
		delay 1
		tell process MyappName
			set visible to true
			set frontmost to true
		end tell
		set value of text field 1 of window of process MyappName to "Just testing"
	end tell

I had this idea earlier today but it didn’t work. So far, it has been working on 10.14. I’ll start testing in 10.13.

Cheers.

[ShaneStanley]

@Garry: To post code, just precede and it by three tickmarks on a line, and the same at the end. I’ve edited your posts above.

[Garry]

Many thanks, sorry for not doing that.

By the way, my final code is flakey although it still works – sometimes, Safari stays in full screen and just switches to my app.

I noticed a couple of days ago that interrogating AXFullScreen sometimes reported false even though Safari was in full screen. Maybe there are bugs in there. I’ve Googled like mad without luck to try to find other reports on that. Documentation on AXFullScreen is hard to find - can’t find anything on the Apple Developer site.

[ShaneStanley]

Version 1.1.1 is now available here:

https://www.macosxautomation.com/applescript/apps/Script_Libs.html

it fixes a bug where the wrong button name was returned from enhanced alerts.

[ngan]

@ShaneStanley, I want to thank you for offering this fantastic utility.

I have written a dialog box with about 60 control variables (17 checkboxes, 5 fields, 5 matrix controls each with 2 options, 2 popup and their related control labels and 20+ pure labels and rules ) for setting the external preferences (I only need to load this dialog occasionally) of a script. It takes 1 sec+ to load in SD (perfectly fine response time) but as long as 4-5 secs (not every time) to popup when it is loaded as a user script on a 32GB 8-core Xeon system. I wonder if there is any general rules to improve the loading time by not having to reduce the number of controls?

Thank you very much!

[ShaneStanley]

Are you running it as an app, or how?

[ngan]

Running as a script, being placed in the application’s script menu of Devonthink V3. I don’t think this is an issue related to Dialog Toolkit at all because the dialog also opens fast from the Apple script folder. That’s why I wonder whether there are general tips for overall performance improvement - I’m now reducing the number of unnecessary label-only and rule controls to see if that helps.

Thanks again.

[rstebler]

This works great! Thanks.

Any chance there is a version of this that works with a url vs a locally stored image?

[ShaneStanley]

The image is going to have to be downloaded first.