Hope I'm not overstaying my welcome with another suggestions thread. I was absent from this forum for a full year prior to this March, and have been slowly gathering up and posting my bugs/suggestions backlog. (This is the last of it!)
1. A
$split (= $true|false) identifier, and a
/split [on|off] command, so scripts can check/change the "Split long channel/query messages" setting. This would be (immensely) useful for scripts that need to exempt certain messages from splitting, but whose authors don't want to force script users to disable splitting client-wide (i.e., scripts could do "
var %s = $split | /split off | /msg $target Message I absolutely never want to be split | /split $iif(%s,on,off)").
2. A
$dqwindow (= $true|$false) identifier. Currently, scripts can enable/disable the window with /dqwindow on/off, but must use $readini to check its status. However, since the /dqwindow command doesn't update mirc.ini, $readini may not return its true present status. You must therefore do /saveini + $readini. (This also means mirc.ini gets write/read hammered if the check needs to happen with each incoming PRIVMSG, and if lots arrive in rapid succession.)
3. Could Ctrl-F matches in the script editor be made to position the highlighted word more towards (if not directly in) the vertical center of the window, rather than only 5 lines from the top, as currently happens? The present behavior somewhat causes you to lose your locational bearings, as it throws most of what's above the match out of view (which often includes the "ON :XXXXX:{" or "alias {" line for the event/alias Ctrl-F found your match in).
4. If a /query window is open to Nick and you type "/msg Nick text here" or "/describe Nick text here" in a different window, the localized echoing of your message appears in Nick's /query window. This makes sense, and is good because it ensures that the logfile for Nick's /query window doesn't miss outgoing private messages to him simply because you lazily typed them from other windows. However, if you don't have a /query open to Nick, but instead have /dqwindow on, typing "/msg Nick text here" or "/describe Nick text here" in a window other than /dqwindow causes the localized echoing of your message to appear in the same window you typed the command in. If /dqwindow is on, wouldn't it be best if mIRC's local echoing behavior for /msg and /describe match what happens if a /query were open to the person (meaning, for mIRC to show your outgoing /msg's and /describe's in /dqwindow regardless of which windows you type them in, so your dqwindow logfile can be similarly complete)?
5. The "Copy messages to query" function will repeatedly copy the same text, over and over, from /dqwindow to a /query window if you repeatedly close and re-open a /query window to the same person (something that can really trash up your log files if you log query chats). Also, as a separate issue, if you use TEXT/ACTION/INPUT events to haltdef the default dqwindow text (so you can "echo -d" each line in your own format) -- or, if you use a /msg alias which sends your text using !.msg coupled with an "echo -d" in your own format -- then the copying mechanism will ignore any echo'd lines which do not begin with one of these exact syntaxes:
- [timestamp] *^K##Bob^O*
- [timestamp] *Bob*
- *^K##Bob^O*
- *Bob*
- [timestamp] * Bob
- * Bob
Both of these issues appear to be a result of the copy-to-query function figuring out which lines to copy by simply parsing visible text in /dqwindow. To solve both, would it be possible to have dqwindow store each of its lines in memory using a format similar to this?
- from,to,<actual text displayed on line>
Example:
- mynick@undernet,bob@undernet,[00:05:31] *mynick* Are you there?
- bob@undernet,mynick@undernet,[00:05:43] *bob* yes
This way, the copy-to-query function could avoid re-copying the same text twice by (a) relying on the extra fields to detect which lines to copy, and by (b) nulling them as it copies, so they will never match again during a subsequent copy-to-query. /echo -d could then be modified to let scripts specify the from/to values on the echo line itself, so that echo'ed lines would also always copy-to-query properly.
6. And... finally, here's something that I believe would help scripters enormously, and even reduce future requests for new identifiers and commands.
Somewhere in mIRC's source code, there is surely a function() which grabs the current, live, "in memory" values of all of mIRC's settings, and transforms them into .ini lines that are ready to be written to mirc.ini. That function gets called, for example, when a user clicks [OK] in the ALT-O dialog (which leads to mirc.ini being re-saved). I'll call this function CreateIniLine(). Elsewhere in mIRC's source code, an identical but inverse function surely also exists which extracts the parameters from a mirc.ini line that's just been read from disk, and which populates all of mIRC's live, "in memory" variables with that .ini line's parameter values. I'll call that function IngestIniLine(). Well, how about:
- modifying IngestIniLine() so that in addition of obtaining an .ini line from mirc.ini, it can alternatively be fed an .ini line via IngestIniLine(line here), treating that line as if it were read from disk;
- modifying CreateIniLine() so that in addition to constructing an .ini line from mIRC's memory variables and then writing that .ini line to disk, it can instead construct an .ini line from mIRC's memory variables and then, rather than write that line to mirc.ini, return that line.
Then:
- modify the existing $mircini identifier, which doesn't currently accept any parameters, so it optionally can accept parameters -- in the ([np],section,item) format, similar to $readini -- and so that when these parameters are given, it calls CreateIniLine(). Presto: $mircini() now gives scripts access to 100% of mIRC's settings in 100% live form (even those not yet saved to mirc.ini);
- create a companion "/mircini <section> <item> <string>" command which feeds its parameters to IngestIniLine(). Presto: scripts can now alter 100% of mIRC's settings (well, except any you might wish to screen out, like turning on com/dll/decode/run).
Bonus: by having $mircini and /mircini be mere conduits to CreateIniLine() and IngestIniLine(), $mircini()'s and /mircini's code would never require updating when new options were added in the future to mirc.ini. Update CreateIniLine() and IngestIniLine(), and $mircini() and /mircini are automatically "updated" too.
