(1) The /dcc send
dialogue's DCC packet-size drop-down was hard-coded to show 5 lines when mIRC only offered 5 packet size choices. mIRC now offers 8 choices, but the drop-down's vertical depth remains 5 lines, making it impossible to select from all of the available 8 choices with your mouse. (Tested under W98SE only.) http://img243.imageshack.us/img243/9322/xyzxp3.png
(2) Uncertain whether by design or a bug, but it seems that $rawmsg isn't populated if used within the match evaluation phase of an event. Only discovered this after trying to do something a little unconventional...
I posted this message
recently, asking how to detect "normal" incoming DCC chat/send attempts in a script. (I had discovered the DCCSERVER event in mIRC's documentation, but saw that it was only for fserve-based DCC sends/chats.) In the end, no advice on detecting "normal" inbound DCCs was forthcoming, so I thought of and attempted the following "hack" to solve my problem:
ctcp *:$($iif(: $+ $chr(1) $+ DCC
,aStringWeHopeWillNeverOccur)):?:echo -s True incoming DCC detected!
mIRC internally removes $chr(1) from CTCPs before event match evaluations, making ctcp *:$($chr(1) $+ DCC*):?:
impossible. And ctcp *:DCC*:?:
would match both
DCCs and user-typed CTCPs beginning with "DCC." So this hack only "lets" the match evaluation see "DCC*" if it's an actual
DCC. Problem was, I discovered $rawmsg == $null during the ctcp *:evaluation phase
:*: of the event. D'oh! I'm certian the "hack" works otherwise, because ctcp *:$($iif(1 == 1,DCC*,aStringWeHopeWillNeverOccur)):?:
itself matches on DCC attempts just fine -- just without the desired protection against user-typed "DCC*" CTCP messages.