Thank you Onslaught for the perfect illustration of the problem Khaled faces in trying to implement dialog functionality..
As much is he will implement, people will always want more control. And the UI's change faster than any one person can keep up with. 3 years ago, "auto complete" forms would not be of any expectation in interface design. The fact that it is now does not justify immediate inclusion into the program.
The true solution here isn't to make compilation list of every single dialog feature you expect to see in the next version of mIRC. This top down approach will be impossible for K to maintain or keep up with. It will result in Khaled spending all of his resources building high level widgets for every use case possibility. Is mIRC an IRC client, or is it a windowing toolkit?
No, the true solution here is to ditch the lists and work from the bottom up, not the top down.
If the dialog problem is to be solved, Khaled needs to write a low level api for the "controls" themselves. This means that a "checkbox" should be no functionally different from a "listbox"-- they are both controls. The only difference would be how each one draws and how each one redraws after interaction.
Doing this would allow anyone to modify he behaviour of any control indiscriminantly of its type. Khaled would not need to implement "autocomplete" for the edit control only to have someone ask to have it implemented for a listbox selection.
Doing this would also allow people like Onslaught who want autocompletion or other customized intefaces to implement it themselves.
Onslaught alluded to a good point here through his example of events. The real way to do this is to add low level event handlers (focus, keys, mouse clicks) coupled with low level interaction ability-- this means anything as far as being able to custom draw the control yourself, in its entirety, borders, custom text and all. This would be much like picwins are now, but instead with a direct handle to the window and GDI context.
At that point, anyone who wants a blue checkbox can go and do it, without having Khaled implement "background colours for checkboxes", "background colours for listboxes", "background colours for ....", etc.
Most of the requests in the original list could be consolidated into: "handle more events and allow custom drawing of a control"
Obviously mIRC is missing some basic controls and those would not be expected to be implemented by the user (richedit, etc.).. but these basic controls are few and could be dealt with easily at any point in time. The real issues are about the ability to truly control dialogs. Richedits (especially) are essentially useless without the low level control described above, given the amount of functionality they contain. It would be impossible to have a customized interface for all of its functionality.
