I'm not entirely sure that just because the behaviour hasn't changed in N years that it should work
Indeed, that's not what makes it a bug or not.
By your logic, the fact that $input() does what it does now means that it can't be a bug, since it's been that way for so long. I certainly don't believe that's true, and I doubt you do too--
Not sure why you bring "my logic" here if you doubt I beleive in it, but indeed, it's not true.
my point is that it's just as plausible that u was never really meant to work properly with dialog windows.
You might be right, but frankly, seeing how the behavior is consitent and is working as it should, I do think $input(,u,) is supposed to work with dialog windows, better, why wouldn't it ? There would be a note in the help file..
I guess the question is this: is using the 'u' switch *really* the recommended way to make a modal dialog with $input?
I don't want to make a modal dialog with $input, I just don't want people to be able to access the dialog if an $input from my code is called, ie: I do want the u switch, I do want the dialog to be the parent window of that $input.
The behaviour of "use the current active window as the parent window" doesn't really sound like that's what it is for.. so while you may have been getting the behaviour you want, it might have just been a side-effect, not a feature. In fact, the fact that u makes the dialog modal might be a bug in itself. There's no equivalent way to make an $input modeless in a non-dialog scenario (//echo -a $input(x) from a channel/status window is modal, same with the u switch), so maybe this was never intentional.
I think you misunderstood the situation because you go astray here, "use the current active window as the parent window" does really sound like what I need, it's not a side effect, there's just this problem related to the script editor
Anyway, of course and as usual, hearing khaled on this would definitely help us
