Here is the extension of Dialog Toolkit Plus that I’m working on.
This is a script library that works with Dialog Toolkit Plus, adding the ability to display and get results from Date Pickers and other Accessory Views.
Included are
Dialog Toolkit Plus Extended Script Library
A Sample Script
A collections of clippings that can be used with Dialog Toolkit Plus and/or Dialog Toolkit Plus Extended
This does not modify Dialog Toolkit Plus in any way and does not interfere with new or existing scripts using Dialog Toolkit Plus.
Hey, Dean, have a look at Dialog Toolkit Plus Extended. I’m thinking it would work with your color popups.
I think this would be a good thread to collect Dialog Toolkit addons.
As for a time-out, if you don’t pass a giving up value to a Dialog Toolkit Plus window or alert command it does not time out for as long as the dialog is displayed.
I can’t open “Dialog Toolkit Plus Extended.scptd” in Script Debugger - bangs an error: “Cannot open file because it does not appear to be a script”. In Script Debugger, I’ve tried to run the sampler but when compiling bangs an error: “Scripting component error.”
Oddly, the library opens and the sampler compiles and runs in Script Editor with no trouble.
I have no idea why that would happen. Opened that version in ScriptDebugger on a couple of Macs, and shared it with a couple of users who installed it themselves from the zip and had no problem. Here’s another zip with just the library. See if you can open and run this.
@estockly I just got around to reviewing this and playing… pretty cool method of adding to Shanes toolkit. Still trying to wrap my head around a couple things.
Few questions…
Have you seen any issues with having an earlier version listed than the actual version?
In your sampler/demo script, you have both use script libraries, do you need both or can it be eliminated If you loaded it at the beginning of your library? Is there a downside to eliminating
use script “Dialog Toolkit Plus” version “1.1”
from the demo script?
3. At the end of your library you have stray code. Is there any potential complications with scripts using the library if left there? I like the fact you have examples in the library if in there but wondering if there’s downside.
Lastly, I started to ask how come you didn’t just leave the extended dialog/alert out of the library but once the morning caffeine kicked in realized that you introduced a new class to the dialog. “Extensions” to Shanes library… IE: date extension, color popups, etc was a great contribution instead of altering the original. I will add mine to this Topic once I properly document it. Thanks for starting this.
No I haven’t had any issues, and the idea was to be backward compatible as much as possible.
The version number specifies the minimal version, it will run with, but that doesn’t stop it running with the current version or (hopefully) future versions.
Yes. You need both if you want to run with these accessory views in this way. The only thing the extended version does is provide the display window and display dialog commands (and the date picker commands). All the other cool dialog toolkit stuff uses the original.
The idea being you would only need to use this version to get good results from date pickers and other accessory views.
If you just want one dictionary, you could make a copy of Shane’s version and copy the handlers from this one into that and use that. That was my original plan but then I realized that this way I don’t have to rewrite all those scripts deployed using the original, and it should keep working with updates to the original.
I really don’t think it would have any effect at all. It’s not in any handler that would be called. It is executable code, and I use it to debug and test. If you open the library in Script Debugger that code is executable and will display a window and a dialog each with different date picker versions.
in your library, isn’t that enough? and that any script using yours could simply call yours only since yours loads it already? Is there a downside to this?