For some reason, this button will not call the OnClick() function. The DOpus.Dlg.Folder() method seems to be the cause (somehow).
If I comment it out, or assign the path to the var "MainFolder" by a regular string var, OnClick() will be called as expected again.
[code]@script jscript
var MainFolder = DOpus.Dlg.Folder("Select Folder","D:\tmp\2015_11_12_delme");
DOpus.Output("Does get here!");
function OnClick(data){
DOpus.Output("Does not get here!");
}[/code]
Any ideas? Thx! o)
I do that because it's totally valid syntax for a script and the outer context is executed after all. I often setup vars out of the OnClick() function, because it's more clear to me and people what this button works on and what is meant to take custom values. It's also a nice counterpart to the @set modifier, which is used in regular buttons right at the top most of the time.
What's just weird is that this special method call (which ran successful btw.) will break the button. The following variation works fine (just removed the call to DOpus.Dlg.Folder()). It also makes use of the global context, but does not give unexpected results, it enters the OnClick().
[code]@script jscript
var MainFolder = "D:\tmp\2015_11_12_delme";
DOpus.Output("Does get here!");
function OnClick(data){
DOpus.Output("Does also get here!");
}[/code]
We define where DOpus.Dlg.Folder can be called, and that's not valid.
You should be using data.Func.Dlg.Folder anyway, so the parent window is set correctly to the lister/tab.
(Or using DOpus.Dlg and setting its parent to the lister before calling Folder, which you still can't do outside of OnClick because you need details from OnClick's argument.)
It may have that parent-window drawback, but since the method successfully opens a dialog and other code runs fine as well, I feel that "we define" is not optimal. You're leaving terrain here. The terrain of consistency and common expectations when dealing with an API.
My primary goal on this is to give a hint on something that gets you stuck, since it works against the rules. Bending the rules is fine at times, but the scripting should try to not create another condition/exception/command-dependency hell that we already have in the older button system.