Forums Feature Suggestions Missing Documentation

This thread has been started as a place for people to list all the functionality that is not yet documented in the help file:

As a starter (by x-referencing versions.txt since 6.17 with help file):

• aline / iline / sline / etc. -t
• $cb(N,u)
• /setlayer
• /toolbar -v
• $window.lb
• $encode/$decode -celsirznp support for salt/iv
• $msgstamp
• $onlineserver / $onlinetotal
• /timer -z
• /sockopen -t
• /list -n
• $tempfn
• /rename -f / /copy -f
• $samepath
• $chan().iql / $iql()
• /ialfill
• $eventid

I don't claim that this list is definitive. Please add any you think are missing.

Perhaps khaled might consider open sourcing the help file on github so that the community can improve the documentation.

Probably not a bad idea to start the list, however Khaled stated the best move would be to start an online wiki, which already exists and also has tutorial on all scripting features: https://en.wikichip.org/wiki/mirc
All commands are documented (except for /ialfill) but only half of identifiers are.

Many of us still use the local help file, and this is also available online and also available through "/help command" - so community updated help would be more generic and convenient than a wiki which is only online and not linked.

All commands except /ialfill ... and /setlayer ... and /drawsize and ...

That's why I said this is still a good idea, I myself still ask for the help to be updated.

/setlayer is there, /ialfill and /drawsize are quite new, that's why there aren't, anyone can add them.

Comparing the list of commands on the wiki, it appears that the following additional commands are missing from the help file:

• /ctcp
• /finger
• /fsend
• /hotlink
• /leave
• /registration

The wiki is also incomplete and has the following commands missing:

• /join
• /kick
• /nick
• /nickserv
• /notice
• /topic
• /whois

The point of wikichip is to document all the existing identifiers, the removed ones and the deprecated ones, some command and identifier are not documented on purpose in the help file, while some are just undocumented.
/finger is an old things which I believe was removed, (some command support switch which means 'use the finger window'), this shouldn't be documented in the help file.
Wikichip is not missing the commands you listed, there aren't mIRC commands, they are IRC server command, for instance /nickserv is not even a thing, only IRC dealing with nickserv may have this command, it's not even mandatory.

/returnex

There are some /commands and $identifiers that have no cataloging, neither in help nor in versions.txt

I really do not know why, but some reason exists.

Example: /bdup

Another example refers to this topic
Before I even asked, there was support for the "-a" switch, if I remember correctly, since version 7.42. However, the "-a" switch was only officially cataloged in version 7.48

versions.txt 7.48:

"32.Added -a switch to all binary variable commands that makes them not apply UTF-8 encoding to characters in the range 0-255, as long as the line contains no characters > 255."

The interesting thing would be to catalog everyone in the official mirc help file, but we have the wikichip where users can do it.

I will assist today with the identifier: $regerrstr
Note: I have no idea what it is for. However, by name, it seems to have something to do with regex.

I think this used to be a good starting point:
https://forum.swiftirc.net/viewtopic.php?f=36&t=16859

Heh, sadly I remembered from your post that you were saying you couldn't get $regerrstr to work (where in fact you said you had no idea what it's for).
Luckily it came up on IRC and after quick testing it's exactly what the name suggests: it returns the PCRE string version of the error code returned by the different PCRE regex function calls.

@Khaled: I don't know why $regerrstr is undocumented but it is pretty useful to know if a pattern fails because of an error or because there is no match found. Please document this identifier.

I saw it on the channel.

Thank you.

The new on hotlink syntax with $hotlink and /hotlink aren't documented: https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/260721/

The new -p switch on /var and /set isn't documented

The new /fupdate isn't documented

2 that are currently bugging me are to do with the Dialog List 'control' and, in particluar, the styles size and extsel,

Both are mentioned in mIRC Help as far as their existance -
'list id, x y w h, style (sort, extsel, multsel, size, vsbar, hsbar, check, radio)'

but no explation.

WikiChip has extsel with -
'Allows extra selection support',
but nothing further. What extra selction support ?

So what do they do ?

it means you can control how you select item in the list, namely using the control key and clicking

I edited the wikichip explanation to illustrate the difference using the word 'consecutive'.

I think I saw that explanation, but to me that sounds like a description of the style multsel which allows multiple entries to be selected using the control key and click together.

Isn't that what you just said about extsel ? or have I mixed the 2 styles up ?

That's right, sorry, feel free to edit back on wikichip if you want, I'll do it later if not done.

05/09/2000 - mIRC v5.8


Missing the -o.

Thanks, however the -o switch was made the default in later versions, so it was no longer needed.

Missing details from help file.

/fupdate hole command informations.
-p parameter from /set command.

$window().cx $window().cy, $mouse.cx and $mouse.cy are missing from the help file.

7.52's /fupdate and 7.53's $caller not documented in /help

also, if the /fupdate setting isn't going to be saved to mirc.ini [options], could there be something like an $fupdate identifier which returns the 0-100 value shown by /fupdate? This would allow scripts to save/restore the existing value, so they could change it during a specific burst of output.

/help /dll says:



Could the dll page be updated from '900 chars' to indicate the current max limit in bytes, now that Unicode means chars and bytes aren't the same thing?

Most DLL's won't care as long as the length is longer than 8292, but the info would be useful for a DLL which needs to support languages from the unicode codepoints above 2047 where each 'char' requires 3 bytes.

I've only tested 'data but not 'parms', but 900 appears to be an obsolete number from older 6.x versions which had that shorter line length. I tested to see how long of a text string of hex digits could be written into 'data' for sending back to mIRC, before it crashes mIRC. The byte length in 6.35 seems to be a few dozen bytes longer than than the 4150 limit. In 7.52 the byte length limit was somewhere around 8400 bytes, I'm assuming this extra length is for supporting multi-byte unicode characters. And now that the line length limit has doubled, the valid string bytes-length has doubled above 16k.

In the mirc 7.56 there's no help info about $urlget. It will be good if the mirc.chm will be updated in time. I don't know about other changes/adds if they are

/help $ltimer

both locations says it returns the number of the timer. Should say 'timer ID'

//timerfoobar $+ $rand(1,99) 1 1 noop | echo -a $ltimer

$file().attr is returning a bunch of letter which are different from what one can read on the internet.
I believe mIRC is translating the constant here https://docs.microsoft.com/fr-fr/windows/win32/fileio/file-attribute-constants to various letters, if some can be obvious, others aren't, it would be great to have a documentation of each possible letter.

It looks like $urlget can return 0 when the connection is refused or something. I'm doing a lot of successive $urlget call via milliseconds timers and at some points i get 0 from $urlget, I'm not sure if this is a bug but I'm assuming the website is refusing my connecting as an antispam protection and that cause $urlget to return 0. My point is that in this case the callback alias won't be triggered, all of this is not documented, it would be nice to know what 0 really means and how it's not going to trigger the callback alias.

/loadbuf -g

-g = ?? (it's undocumented)

Missing $evalnext() identifier

Examples should be changed since root folder of c:\ has been read-only for a long time, unless mIRC is running in $isadmin=$true mode. It's hard to tell if there are other similar path strings elsewhere in /help since the search function returns a lot of false matches

/write -c c:\info.txt This file will be erased and have this line written to it
/write -c c:\info.txt This file will be erased and have this line written to it
/write -il5 c:\info.txt This line will be inserted at the 5th line in the file
/write -dl5 c:\info.txt
/write -dstest c:\info.txt

edit: this is in response to someone coming into channel asking why the /write command in the /help doesn't work

Thanks, I've removed all references to c:\ from the help file.

While making this answer to a question
https://forums.mirc.com/ubbthreads....-you-must-specify-a-parameter#Post268998

I noticed that labels in popups aren't behaving the same way as the command following the semi-colon.

When more than 1 nick is highlighted, the command following the semi-colon sees $2 $3 etc get filled in, but they are not filled as seen by the menu label. While it is true that the /help doesn't mention anything beyond $1, the default popups menu does contain them and the command here does use them:

.Op:/mode # +ooo $$1 $2 $3

... and users could see unexpected behavior if they assume that $2 behaves the same way across the entire label if you have the following lines in the nicklist popup menu:

Label (0) $0 (1-) $1- parms $parms (2) $2 : echo -a (0) $0 (1-) $1- parms $parms (2) $2
.Give Op to $1-3:/mode # +ooo $$1 $2 $3

In the label, the $0 is always 1 when $2- is filled due to more than 1 nick selected, $parms is always ignoring the presence of $2- nicks, and $2- $2 $3 etc are always blank. This can result in a menu command targeting a different group of nicks than indicated by the label, ie giving ops to 3 nicks even though the label says only 1 nick.

Whether $2- should become part of the menu label, or the /help should be updated to indicate that $2- are valid in the :/command portion, I dunno.

$lock(sendmessage) ; 7.34
$min()/$max() .text .textcs ; 7.62
/hotlink -dm ; 7.23

It appears that $lock is having backwards compatibility for obsolete functionality, where it returns $false for things no longer able to be disabled from the menu. This $false reply also happens for things including:

//echo -a $lock(decode) $lock(run) $lock(com) $lock(dll)

My reply wasn't completely accurate. $lock(sendmessage) is not one of the other obsolete features returning $false. Instead, the option to enable or disable it is on options/other, instead of being at options/other/lock along with the other active remaining items.

Based on the different behavior of these 2 commands, it appears that 'v' is an undocumented switch, so it would be great if F1 help could tell us what -v does.

/echo -jkopuwxyz
/echo -jkopuvwxyz

If -v turns out to be a 'do nothing switch letter that will never be used as a valid switch' as referenced HERE that would also be helpful if it were documented.

The documentation for the /*line commands could be made more clear by having the syntax line showing the location for the switch letters. Especially since it's different than for /echo because the switch letter goes before the color index instead of after.

i.e.
/aline -a 4 abc
vs
/echo 4 -a abc

It's probably from /drawtext -v &binvar being passed to /echo internally. Or it's an experiment where Khaled tried, or anticipated, adding &binvar support to /echo in order to print things like sequential spaces.

$read documentation vs behavior

I assume at this point the fix is to clarify F1 help rather than to change the behavior of $read, since that would behavior that's not backwards compatible.

The description of $read's 't' switch makes users understand it to be saying that that avoiding using the 't' switch while the top line of a text file is an integer - would allow the 's' and 'w' and 'r' switches to mimic the behavior of $read(file,n) where a small integer as the top line of a text file could allow the search range to be restricted across only a portion of the file.

Instead, using the 's' switch with/without the 't' switch has identical behavior except for having $readn returning a decremented integer if the 't' switch isn't used when the top line is an integer.

i.e. I was expecting the next example to fail to find a match since the match wasn't within the 1st 2 lines, but instead the only difference is whether $readn returns 5 or 4:

//write -c foobar.txt $+(2,$crlf,a1,$crlf,b2,$crlf,c3,$crlf,xyz aaa) | echo -a $read(foobar.txt,nts,xyz) $readn : $read(foobar.txt,ns,xyz) $readn

I don't know whether this would deserve having the t switch changed to be a tN the same way there's a wN subswitch.

The beta changelog does not mention two new props for $notify, $notify().away $notify().awaymsg.

I added these for testing purposes. I will be removing them from the next beta as they are not reliable. See here for an explanation.

$ial().bot

/help /topic

doesn't show the -r switch
states this can be used to change topic, but doesn't mention removing or just displaying it

/echo [color] has "0 to 15". Should that be "0 to 98"?

https://forums.mirc.com/ubbthreads.php/topics/270602/add-missing-mouse-key-bitmasks

Referencing the other thread. v7.71 enables the new bitmasks but the /help lists only those up through 16.


I'm taking it on faith that 32 is the mouse's middle button, because I don't have one. A middle button, not a mouse.

A reminder to all that an alternative source of documentation which is maintained by the community is Wikichip.

$wrap(text, font, size, width, bipt, N)

the 'w' switch is mentioned in the lower text, but not in the above syntax.

/alias -s

https://forums.mirc.com/ubbthreads.php/topics/246550/alias-runs-silently

The /help Key Combinations
page can be fleshed out with missing hotkeys. I looked to see if the ctrl+shift+del window mentioned by eahms was there, and found it wasn't the only thing missing

alt+A / alt+J / alt+D for favorites and/or aliases
alt+B addressbook
alt+C chat
alt+E server-connect window
alt+I online timer
alt+K colors
alt+L channel list
alt+N Notify list
alt+O options menu
alt+P popups
alt+R script editor
alt+S dcc send
alt+U toggle Urls

Some navigation keys are missing or incomplete.
For Ctrl+Home and Ctrl+End the description reads as if it applies only to the editbox, but is in a section outside of "Editbox keys". And then a lot of editbox and script editor navigation keys are missing, such as Ctrl+Backspace, Shift+Home/End, shift+leftclick, Ctrl+Left/Right Arrows, etc

I'm used to seeing these described as arrow, so took me a little bit to figure out what 'cursor' meant here, since that usually means the position where the cursor is blinking. Likewise figuring out that 'copy' in several places means 'holding the left mouse button down'

For the items explained in other pages, can simply have a hyperlink instead of repeating the description

Recently added: $server().connect and $server().minimized corresponding to the new server list option

Added a long time ago: /window -T I think it's supposed to allow the shift + tab option for nicklist which toggle the nicklist (sidelistbox) on/off when you have it to auto hide. I couldn't get that behavior to work.

Searching from the Nth line onward in $fline requires the T parameter to be passed as 0, passing $null fails. The help file should clarify this, I almost wrote a bug report.

I still believe that open-sourcing the help file on Github would not be a major Intellectual Property issue, but would enable the community to update the help file contents for the benefit of all.

And I would also say the same for servers.ini - putting this on Github would allow the community to make servers.ini both more comprehensive and reflect the churn of IRC servers. I suspect that this would also result in a community member creating a script to update existing users servers.ini file from a new servers.ini file downloaded from Github.

All that said, this is entirely up to Khaled (since he owns the IP) and it is completely understandable (and completely within his rights) if he decides he doesn't wish to open source these two items.