Can I have a modal dialog which is dynamically populated?
I mean, I use dlg.Create, do all my setup and then set dlg.detach = false, then after dlg.Show window just blinks and that's it. After adding event loop, all code works.
I tried this with JavaScript.
From the manual:
Using the Create method implies a detached dialog - that is, the detach property will be implicitly set to True .
You can use dlg.window (and dlg.disable_window) with a detached dialog to disable the lister that launched it if thats what you’re trying to do
Yeah, I know this information, however it mentions just setting the property automatically and nothing else. I know workarounds as well.
Just it seems to me it's a very strange limitation. Think for example about the simplest things, like customized delete dialogs.
I don’t understand the problem. Why not use a detached dialog? Why must it be a simple dialog?
It's not a matter of possible/not possible, but a matter of the API design.
Think of Java Date/Time API from before v8. Yeah, everything was possible with it, just if was so f** up, that everyone used Joda Time.
To put it in other way, marrying dynamic control population with dialog modalness is something completely unexpected as there is no logical connection between the two.
I have been dabbling in javascript for 3 months and have no idea what you’re talking about re. Date/time and joda. 
I genuinely thought you were asking for help with a DOpus script issue not making a point about something that doesn’t work the way you think it should work.
I asked a straight question, which documentation doesn't answer. My question was related to the API, and not to reaching any specific goal.
As for this specific thing, it's rather a question to Jon why it's not working (re bad/good API design) - is it just overlooked, technical limitation, bug. To me it looks like the detach property is a boolean settable only in False->True direction. If this is the way DOpus works, it does not automatically means it is the right way.
Thanks, that's it.
However it screams confusing.
Clean flow for me would be 1. obtain dialog (Create, Dlg, whatever) 2. configure (including template and mode, default mode possible) 3. show (with a single function) 4. consume values (modal) or run event loop (non-modal).
Now it's a mess. 1. I can use Create, but then I get non-modal dialog which I display with Show. 2. But when I don't use Create and just run Show, I get modal dialog. 3. Moreover, in order to display modal dialog as non-modal I need to use RunDlg (ShowDlg would be so much easier to spot), 4. And there exists detach property, which I can use to turn modal into non-modal without using Create apparently.
It's now like:
Dlg -> Show (modal)
Dlg -> detach = true -> Show (non-modal)
Dlg -> Create -> Show (non-modal)
Dlg -> Create -> detach = false -> Show (now working)
Dlg -> Create -> RunDlg (modal)
Dlg -> RunDlg (???)
Isn't it just overcomplicated?
Can't you just to call Create, do your setup, then call RunDlg?
Do you think this API has correct design? Like, it works, now let's make it better?
You don't need to touch the detach property, as far as I can tell.
Assuming this works:
- Create
- Do whatever setup you want
- RunDlg
Then yes, I think it is correct. I cannot see anything that needs improving there, except maybe the documentation.
If that doesn't work, let us know.
OK, here's my mock proposal:
Dlg -> <set properties> -> Show()
Dlg -> <set properties> -> ShowNonModal()
Assuming that just modifying number of objects/elements in a system without reducing its functionality (no Create, no detach) is an improvement, this would be one.
I am not even discussing effect of the design on ease of use, logic flow consistency or "the least surprise" rule and likes, because they can be subjective.
Frankly, I don't think you are going to do anything about it, but there are such things that make using Opus API really confusing, at least for me. (Why the heck ClickData has everything in a func attribute instead of being a func itself?)
So your complaint is with the names of the methods, not anything else?
Ummm, no. I would not call it a complaint either.
But really, if you don't see the point, I don't think I can elaborate it better. And anyways API breaking changes are something no-one likes.
At least now I know what I need.
Thanks again.