Forums Feature Suggestions A few miscellaneous suggestions

(1) View > Font from the menu bar currently opens a Font control dialogue box for whatever mIRC window is currently in focus. However, you can already configure any currently-focused window's font via that window's top-left-icon dropdown menu. That said, why not "repurpose" View > Font so it takes you to a "master font control" interface window of some kind, where from that one central location, you can see and configure every possible font setting for every possible window type in mIRC? This would be very handy for people who're re-installing mIRC and would like to quickly re-establish their preferred fonts for different things without having to go around "invoking" every possible window type to do so. (I.e., otherwise, I have to do things like send a DCC just to configure the DCC send dialogue's font, then ask somebody to send me a DCC just so I can configure the DCC get dialogue's font, etc., etc.)

(2) As per traditional Windows Explorer behavior, how about making the log file viewer's [Delete] button accept shift-clicking in order to delete selected log file(s) without sending them to the recycle bin? (I.e., there should still be a yes/no confirmation box; but instead of saying "Are you sure you want to move the selected file(s) to the recycle bin?", it would read "Are you sure you want to delete the selected file(s) without sending them to the recycle bin?" -- or whatever.)

(2b) Since it is instinctive to also "want this to work" (on account of Windows Explorer habits), perhaps the log file viewer can also accept the keyboard [DEL] key to delete selected log file(s) (including the possibility of [SHIFT]-[DEL] for avoiding the recycle bin). (The delete/recycle yes/no confirmation boxes should appear with this method too.)

(3) Can the ALT-O dialogue be made to not have "exclusive focus"? I.e., so that when it is open, you can still access and manipulate chat windows? I don't know whether it currently gets exclusive focus on account of programmatic necessities. But if not, allowing the user to at least still chat in channel/query/dcc chat windows when it is open would be a tremendous benefit. I can't count the number of times I've helped someone with elaborate mIRC configuration guidance, but where I had to repeatedly raise and lower the ALT-O dialogue throughout the process to be able to type each next step to them.

(4) Can you make the Log View dialogue box resizable? (As it is, it is horizontally small enough that one must always use the horizontal scroll bar in the log file list to see everything. Being able to make the entire dialogue box wider would alleviate this in most cases.)

(5) Finally, could the 'echo' command be enhanced to allow line insertion at the point where a channel window was last opened/rejoined? In other words, where the following sequence of echo commands would have the following respective effects:

echo -o This line will appear above the "* Now talking in #channel" / "* Rejoined channel #channel" line, and below the last reloaded log line (if any)
echo -o This line will appear above the "* Now talking in #channel" / "* Rejoined channel #channel" line, and below the last echo -o line added

My reasoning for this suggestion is twofold:

(a) it would enable a script to add informational text to a channel window on the exact line at which it is opened/rejoined, in cases where said script does not yet know the information to be written to said window when it is opened/rejoined. (Yes, maybe there's a way to use ON [^]OPEN/[^]JOIN trickery to perhaps accomplish information gathering ahead of the appearance of "* Now talking in #channel" / "* Rejoined channel #channel". But that would only be suitable for cases where the time required for the script to gather that information wasn't lengthy. With an echo -o option, on the other hand, that time period could be technically infinite. But in practical terms, it would allow mIRC to spend 5-6 seconds gathering information in some way and then write it to the join/rejoin line location even if people have already typed a few lines of text in the channel by then.

(b) -o would enable a seriously awesome (IMHO) scripting possibility involving channel bots which keep chat logs (and thus which know when a user last parted/quit). That feature? BNC-like backfilling without having to use a BNC. IOW, the ability for a channel bot to backfill your channel window with loglines of all the chat you've missed since last being in the channel. When the backfill operation finished, you would be able to scroll upwards and see completely uninterrupted chat -- your reloaded mIRC logs seguing into the backfilled lines seguing into your join/rejoin. (Yes: all the particulars of how this would work "under the hood" -- like when/if the bot sent such data to begin with, and how it would send it to mIRC in the first place -- would be issues left to the bot and the user's mIRC scripting. But at least -o would be the "bedrock" upon which such a trick could be pulled off.)

Anyway, this -o suggestion would obviously have implications for local mIRC .log files. (Lines inserted in a window, if logged, would logically have to be inserted in the .log file at the same location as inserted into the window.) But unless you know some programmer's trick for inserting lines into (possibly multi-megabyte-long) text files quickly, then I suppose this -o suggestion could simply force -g. I.e., use -o, and -g is automatically assumed.

Incidentally, thank you for mIRC. I hope having so many suggestions comes across not as criticisms of inadequacy, but simple enthusiasm for software we all love!

(1) A master font control interface would be nice.

(3) Modal option dialogs make more sense in many cases, because they're easier to control. I'm not too sure "I need to guide someone through the options" warrants making it modeless-- that just seems like a really odd use-case to optimize for. And I say this as someone who spends most of my time on IRC helping others with the client.

(5) Lines cannot be added/removed from channel buffers. Until this is possible, I don't see this happening. FWIW, once lines can be added/removed from channel buffers, an extra echo switch is still not needed because the insertion functionality is already implemented: see /help /iline. Note that /*line aliases are ignored from logfiles anyway, so that would solve the problems you raised. Also keep in mind that the ability to add/remove text from channel buffers was suggested a few times in the past, so it's either been considered and deemed unnecessary, or somewhere on Khaled's todo list already.

(3) Perhaps, then, the ALT-O dialogue could simply be presented in an "always on top" state within the mIRC window, while otherwise being non-modal. That would prevent it from becoming lost beneath other windows, while simultaneously letting you navigate it collaboratively with someone you're chatting with.

(5) Understood. In any case, my suggestion relies on there being some way to insert one or more lines at the line position where a channel window was opened. That line position would be something mIRC would need to internally track, and regardless of whether /echo or /iline was decided upon as the insertion method, there would still need to be a new switch created to specify that the "on open line location" is the desired insertion point.

(3) No, no-- the implementation advantage to modal dialogs is their modal nature, not the "always on top" behaviour. The fact that they "block" until closed is exactly what makes them easier to use in a programmatic context. Khaled *could* switch to modeless dialogs, but it's much easier to just leave it the way it is and save the extra complexity and possible bugs.

(5) The channel window is "opened" at the first line. Buffer reloading would presumably occur after ON ^JOIN and before ON JOIN. You'd just use /iline to insert the text-- again this all depends on text insertion to channel buffers.

Right, but again, the specific nature of my suggestion excludes that as a workable method.

I suggested a way to insert new lines, at the line where the channel was joined/rejoined, even after joining is fully complete.

In that case, you couldn't just do /iline between ON ^JOIN and ON JOIN.

Why not?

It's trivial to keep track of $line(#,0) in an ON JOIN event:



Then you would just use /iline with $hget(initlines,$+($cid,#))

There's no reason to add clutter with an extra command/switch for something that can already be done with minor scripting.

Interesting, thank you. I'll experiment with this.