Hallo! o)
I had some closer look at the new dialog resources and how they are meant to be handled in script addins.
Is appending to the script, prefixed with "== SCRIPT RESOURCES", the finished idea and implementation on this or could it be subject to change within upcoming releases?
Thanks in advance for letting me know! o)
Everything is subject to change.
Assume you had a hard day or something, so I might get back to this another day.
Not at all, I thought you were asking if it was set in stone, or if it was worth suggesting changes?
My reply was to say that nothing is set in stone yet, so suggest away.
Apologies but could not resist. Remember the theme of Il Gattopardo "Se vogliamo che tutto rimanga come è, bisogna che tutto cambi."
@Greg, no I don't remember! o) I tried to translate with google, did not make any sense for me. o)
Now back to the initial topic:
I wonder why you chose to append the dialog resources to script files.
I see several disadvantages with this:
js/vbs syntax breaks
External editor may choke heavily with plain text appended to valid source code.
I'm thinking of:
editing and maintaining script dialog resources is not possible without headaches
scripts cannot share or reuse dialogs (in dialog tabs e.g.)
scripts cannot modify/create/extend dialog xml files directly
This is for people who'd like to go crazy with dialogs. Embedded resources cannot be created by scripts itself. So there's no way to change a dialogs layout or add controls dynamically directly from a script. Example: You cannot add x many checkboxes if you need them, which is something the current "standard" dialogs can do to some extend. Another usecase is to install or publish dialogs by scripts on demand.
Maybe this all is still subject to change and you plan to also support external dialog resources?
To wrap this up, I really see only advantages with external resources and can't think of something that would add inconvenience.
Thanks for your attention, opinions appreciated.
The quote above means "Everything must change in order for things to remain the same."
The next beta will let script add-ins load resources from external files. In the future we'll expand the dialog editor to be able to edit external files as well; but dynamic creation of dialogs is definitely out-of-scope for the moment. No one's even using this stuff yet, so we want to see how it goes before spending too much more time on it.
That's really nice to hear, I mean really nice! o)
I guess you misunderstood me regarding the dynamic dialogs. I was thinking about putting the xml together from script directly with the activex xml dom or just plain strings. I need to look at the xml once more, but I'd think in theory, this should be possible. I was not thinking of a set of methods to create the dialog elements and putting them together with some kind of scripting api. So, all is fine I guess. o)
What's the script you're writing where you've run into a need to dynamically generate dialogs?
If we have an idea of what's driving the need, we're better equipped to improve the API to meet that need and it also makes the need more concrete and less theorerical/hypothetical.
A simple example is this specific dialog control, which is available right now. It can be used to create a dynamic set of checkboxes (in the filter related script dialogs eg., where you'd pick one or two filters to apply). I would not know how to do something like this with the new dialog system. Well, you could open two listboxes side by side and create something that would allow to move filters from the "available" container over to the "apply" container, but that's not something which allows an easy and quick multiple selection. Well, unless you add multiselect feature to the new listboxes. o) Pandoras box is open now. o)
Another example is multi-button requesters with a varying set of action buttons (Yes, No, Cancel, Apply, Save, Reboot).
This is something which is used quite a lot but not covered with the new system as far as I can tell.
The other thing I was thinking of is reusing dialogs (in tabs and elsewhere). It looked like this is something you also thought of, so dialogs or just parts of them could be loaded and used in different places without maintaining copies. Admittedly, this is a bit far, but people have taken things far, so why not lose restrictions like that with a dynamic approach for the DIY people.
Looks like sooner or later it would be cool to be able to put a selfmade xml-representation of a dialog into DOpus.Dlg.CreategFromXML() and boom. Dealing with files already elimitates a lot of drawbacks. This is not directly related to dynamic dialogs of course, but external files don't rule out these dynamic things, since files can be changed and written.
You can add lots of buttons/checkboxes to the dialog resource the normal way, and then show/hide and re-label them at runtime. No need to create the resource itself at runtime just for that kind of thing.
Actually you can do this already, the Dialog.template property can be set to an XML string to define the dialog directly.
@leo
Yes, that might actually for a bunch of situations, must see how things work out when in actual use. I'd think for buttons you'd also need to rearrange/reposition them to adapt to label widths and things, but I think you need to give both attempts a try first to see what really happens and works.
@jon
So .template can take the resource name OR the resource xml data in string notation?
May I suggest multi column list boxes?
Makes sense, yes.