And you are starting to illustrate that you just shoot down new features for the heck of it.
Wrong. I'm saying compiling lengthy lists of each individual feature is going about it the wrong way. The right way to solve the issue is to design bottom up, not top down.
I repeat.
Khaled should improve dialogs and add new features. The features he should add, however, should not be a list of high level custom controls.
Khaled himself added dialog support
So your question "Is mIRC an IRC client, or is it a windowing toolkit?" is completely irrelevant nor any reason to shoot down new features.
Khaled added dialog support, good observation. However "dialog support" is far different in scale from "a windowing toolkit". You would not expect to "do anything" with a UI made from dialog support, whereas a windowing toolkit exists for the sole purpose of complete control. This is not an assumption at all.
Khaled himself chose to make a high level script engine
So shooting down any new features because a low level approach might be better is again irrelevant and no reason to shoot them down. Low level control is even less likely to happen.
The false assumption here is being made by you. Low level does not imply anything will be lower level than the scripting engine itself. I think you're misinterpreting what "low-level" means in the context of UI controls. A "high-level" control in this case would be a "richedit control" whereas a low-level one would be a basic text-box. In fact, the lowest level control would just be a rectangular area inside a window that could be drawn on using *high level scripting functionality*. mIRC has no support for this low level control. Adding such support would solve many problems in the list, though it risks turning mIRC into more of a "windowing toolkit" than it is meant to be (see above)-- again, low level here has nothing to do with scripting in this context.
The fact remains that there are alot of controls/events/commands that can (and perhaps should) be routed to be controled from mIRC
I agree fully. This is exactly what I am asking for as well. The control, however, should start from a lower level. This would give people the ability to roll their own should mIRC not support something natively, without relying on DLLs. Given the ability to custom draw a control, there would no problem for me to implement the "number choice" suggestion by genius_at_work until mIRC added the control natively. I could do so in mIRCscript instead of waiting on Khaled to give me more freedom. This is what I am asking for.
For those who want complete control over everything should look into making picwin GUI's
The difference in implementation to allow complete control in any Windows window is conceptually the same. There should be no reason why complete control is attainable in custom windows (a regular child MDI window) but not in a dialog (a regular desktop window). In fact, I believe this is one of the suggestions in the compilation list.
or think twice whether mIRCScript is even the right tool for the job.
Much better said. But what other tool is there? DLLs are rarely a better tool for UI stuff.
