Ok, well I stated that I wanted a modal $input dialog but $input is always modal.
$input is
not always modal. This is the entire premise of this bug post and discussion. Currently, $input is modeless when called from a dialog unless you pass 'u'-- but 'u' should not activate modality (not according to the description of its behaviour, anyway). You should probably re-read the link I sent above that explains what "modal" means, because I'm not sure you're on the same page with what modality is.
The point is that if you're relying on behaviour that is a
side-effect of a feature and not the feature itself, we should correct the side-effect. In this case that would mean changing how 'u' activates modal $inputs when called from a custom dialog, and then creating another properly named switch that does only one thing: force a modal $input (or potentially force a modeless $input).
Perhaps that real bug here is that $input is modeless when called from a dialog. This is certainly not the behaviour when called from the editbox of a regular window. Maybe $input should be modal by default, then we don't need to worry about 'u' at all (though adding a switch to make it modeless and fixing 'u' would still be needed).
What would be the point of having a parent window for $input regardless of being modal or not ?
Carefully re-read my last post, as I explained the exact reason why you would want to associate a parent window for a modeless dialog (custom or $input).
And finally, just to clarify-- drum is correct, I was referring to the general UI classification of "dialog windows" (dialogs are a subset of "windows", of which mIRC's dialogs are not the
entire subset), not the dialog feature of mIRC. $input is also considered a "dialog".
