|
Joined: Apr 2018
Posts: 83
Babel fish
|
OP
Babel fish
Joined: Apr 2018
Posts: 83 |
I've just been hit by (yet another) occurance of an error message in my status window that I find most unhelpful in a number of cases, it's the * No such identifier: $FormatString or whatever variable the issue is with. If you only have 1 or 2 occurances, or you have only made one change then it's usually simple to track down. Unfortunately with the reported one above, there are around 80 calls coded to that identifier (an alias) throughout a largish script, and yes it does exist and work elsewhere within the code. In fact the most recent changes were all made by copying existing working lines and amending a message at the end of the line - used to output timing information to a custom window. I did track down roughly where the error occured; between a user mode change and my password being accepted by Nickserv, but both of those sections appear to be using the alias correctly - even with my glasses on. The only thing between them is a diagnostic timing output reporting that we are processing 'On Connect' - it doesn't do anything there unless it is a ghosted connection, and it wasn't in this case. The reported issue is probably something like a control code being slipt into the string, but I cant, at this time, find it. Would it be possible to append the offending line number to that type of message, as is already done for other errors ? For reference, this identifier/alias is called by $FormatString($calc($ticks - %Tocks),8).Left to display the time in (approx) milliseconds with left padding (right justify) the 'precise' moment an event occured. [%Tocks is captured at raw 001 and everything else is relative to that] The '8' is the 'field' length to use. Another message that would speed things up is the 'unknown command' one. That isn't so bad since it is usually a mistyped command and can simply be searched for, but it would be quicker with the line number.
Last edited by Erasimus; 04/04/19 02:05 AM.
|
|
|
|
Joined: Feb 2003
Posts: 2,812
Hoopy frood
|
Hoopy frood
Joined: Feb 2003
Posts: 2,812 |
Insofar as tracking down the immediate error right now. If it's an invisible character (control code) that snuck into the $identifier call (as in $Forma#tString()) then hold down the SHIFT key while selecting the error message, and then paste the error message into the editbox or Notepad or elsewhere to examine it for control codes.
You can also perform a Ctrl+F search on the SHIFT-copied identifier name that contains invisible characters, and the editor should be able to find the bad instance.
If your FormatString alias is declared using "ALIAS -l" inside a remote script, then the identifier can only be used locally within that remote script. Remove the -l switch to allow it to work globally.
Well. At least I won lunch. Good philosophy, see good in bad, I like!
|
|
|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
In general, the no-such-identifier message shows the line number, but there are exceptions, such as when the bad identifier is in the label or command on the popups menu. If you think it's a control code touching the identifier, try pasting the next command into the editbox but don't press enter until you've use the ctrl-button to include control codes into the clipboarded text. Then see if there's anything suspicious in that line. You can also try to find the problem characters using /filter. This example searches for the bold code: //filter -fs $qt($script(1)) * $+ $chr(2) $+ * You can find the ascii values for the control codes by pasting them inside the parenthesis. //echo -a $asc() Don't forget about the TAB $chr(9), as I've seen this touching identifiers and invalidating them. Your solution for unknown command won't work, because this is generated by a server message, not by a script line. When you use an invalid /command, after failing to match it to an alias or a built-in command, mirc sends to the $server in hopes it knows what to do with it. After an unknown delay, the server answers back with the raw 421 of the invalid command. What would help is if the error message included the *full* reply sent by the server. It includes the commandline sent along with the bad command, and that often can help figure out where the mistake is located. You can also use a debugging window to snoop at the messages to/from the server. Here's a couple sample /debug commands to show the bad command error message coming from the server. You can then scroll up a little higher to find how much earlier you sent the bad command to it. The different colors helps you more easily find mirc's chatter amongst the larger volume of return messages. The 2nd message shows the hex value of each character in $parms, which can help identify control codes touching the outbound command. Of course as you've implied, $ticks is not the same thing as milliseconds, but showing the lowest 3 digits of $ticks helps identify partial-seconds intervals between events. I prefer seeing the digits in hex because it's easier to read when the display is a fixed 2 digits instead of a variable 1-3. With experience, you can eventually be able to identify certain ranges, such as how the numbers 0-9 are hex 31-39.
debuggvm { !window -ze2Dj5000k @debug | !titlebar @debug active= $+ $~scid($~window(@debug).cid).network logging: $~addtok($~gettok($~window(@debug).titlebar,3-,32),$~network,32) | !debug -pir44o52 @debug $!+([,$~time,.,$~right($~ticks,3),],[,$~cid,],[,$~network,] $~!1 ) } ; Raccoon's altered by maroon v7.52+
debuggv6 { !window -ze2Dj5000k @debug | !titlebar @debug active= $+ $~scid($~window(@debug).cid).network logging: $~addtok($~gettok($~window(@debug).titlebar,3-,32),$~network,32) | !debug -pi @debug $!+($~chr(3),$~iif(->* iswm $~!1,4),[,$~time,.,$~right($~ticks,3),],[,$~cid,],[,$~network,],$~chr(15) $~!1 ) } ; Raccoon's altered by maroon pre7.53
debuggmh1 { !window -ze2Dj5000k @debug | !titlebar @debug active= $+ $~scid($~window(@debug).cid).network logging: $~addtok($~gettok($~window(@debug).titlebar,3-,32),$~network,32) | !debug -pir44o52 @debug $!+([,$~time,.,$~right($~ticks,3),],[,$~cid,],[,$~network,] $~!1 hex: $~!regsubex($~1,/(.)/g,$~base($~asc(\t),10,16,2) $~!+ $~!chr(32)) ) } ; Raccoon's altered by maroon+hex
And a reminder for other readers, the debug command only captures events from the network where you run this command, so you can either place the command in your perform-on-connect for all networks, or only run it when you have problems to fix. I rarely run the hex version except when trying to chase down evasive bugs.
|
|
|
|
Joined: Apr 2018
Posts: 83
Babel fish
|
OP
Babel fish
Joined: Apr 2018
Posts: 83 |
Thanks Raccoon, I had forgotten about the shift key, but when I tried, as suggested, the search simply matched every single occurance of the reported identifier. So it isn't a control code. I did say The reported issue is probably something like a control code being slipt into the string The point remains, identifying the line with the errant call would help. I do know about the -l in the alias definition, and it is used and called within the same script file.
Last edited by Erasimus; 04/04/19 09:22 AM.
|
|
|
|
Joined: Apr 2018
Posts: 83
Babel fish
|
OP
Babel fish
Joined: Apr 2018
Posts: 83 |
Thanks maroon, The bad command was an after thought, and I already use debug while investgating my code. In general, the no-such-identifier message shows the line number Cant say that I have seen that happen, but it could have slipped my mind. but there are exceptions, such as when the bad identifier is in the label or command on the popups menu. Nope, I checked, not in labels or commands. Are there any other exceptions ?
|
|
|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
Are there any other exceptions ? Well, offhand, there's the big example when it's not even on a line. In which case it would be nice for it to report $ctimer /.timer 1 1 echo -a x $no_such_identifier
|
|
|
|
Joined: Feb 2003
Posts: 2,812
Hoopy frood
|
Hoopy frood
Joined: Feb 2003
Posts: 2,812 |
Also, you can't call an "Alias -l" from a /timer.
Well. At least I won lunch. Good philosophy, see good in bad, I like!
|
|
|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
Well, yes and no.
If your identifier or command was a local alias created like alias -l FormatString and is used by timer commands launched from ON CONNECT handlers in several scripts, they all report the local alias as being no-such-identifier or bad-command, except when the timer is launched from within the same scriptfile where the local alias is located.
|
|
|
|
Joined: Jul 2006
Posts: 4,185
Hoopy frood
|
Hoopy frood
Joined: Jul 2006
Posts: 4,185 |
Simply put, if the call of the identifier was from a script file, it should always report the line number, if it's not, you need to report it as a bug. But it seems that you're not sure it's coming from a script file. There are various places in mIRC (in the options) where you can call identifiers, where that shouldn't return a line number, so check for that.
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
Joined: Apr 2018
Posts: 83
Babel fish
|
OP
Babel fish
Joined: Apr 2018
Posts: 83 |
Brilliant Wims.
I had put a line with the call in the perform box (normally I dont use that feature) and forgotten about it. That, coupled with the -l on the alias definition, first mentionted by Raccoon, was the culprit.
As you said, no line number to report so none shown in status window. Explains it nicely.
Thanks also to maroon who pointed out the no line number situation of the timer command and Raccoon (again) for his point about trying to call an alias with -l from a timer.
I really appreciate the info and assistance. Cancel suggestion please.
Last edited by Erasimus; 06/04/19 03:35 AM.
|
|
|
|
|