Forums Feature Suggestions Some sort of 'explicit' mode

mIRC seems to assume that any unhandled command is meant for the server, and sends it off to the server. If it's a bad command or missing alias or something, you will either get an "Unknown Command" response from the server, or "not connected" error message if not connected.

Rather I'd have these unhandled commands treated as an error. If you want to send a unhandled command to the server, a specific command (i.e. /type maybe or is that already taken) must proceed the line.

Example: Suppose I wanted to send the command '/nickserv' to the server... i would use...



Of course not everyone would like this. So, allow scripts to enable some sort of "explicit" mode that treats unhandled commands as errors.

mIRC cannot know all possible commands on all possible IRC networks. That is why it will try to send all commands through the network. That should not be changed.

If an alias is missing from a script surely it would be picked up in bug testing? Users shouldn't be getting errors from the server or mIRC so if there's a chance an alias won't exist for any reason why not check it with $isalias()?

As far as '/type' is concerned, it seems you are forgetting about /quote. Although since i dont believe its documented you could also have been unaware.

/raw is documented though (/quote is mentioned there too, although help implies that it only works in other clients).

Your right, i only did a quick check with /help /quote as i posted. I generally use quote, but given the -q flag for raw i suppose that is actually more useful.

-q works in /quote too, but in any case, since you can silence both /raw and /quote with the usual dot prefix, it's a legacy thing (it's older than the dot).

I know about /quote and /raw...

What I am refering to is errors caused by typos... for example...



The error is being caused by a typo. Offline this error is easy to detect. Online, it would be a little more difficult to track down.

I just have a problem with mIRC sending unhandeled commands to a connected server, rather than treating them as errors. Of course this would be an option declared by the script. It doesn't matter no one understands anyhow.

I understand what you're saying... When the server returns a bad command error, it can't give you a script or line number. So, it's much harder to find the bug.

A better solution might be to not send unknown commands to the server IF they exist in a script, since /raw can be used for this, and instead generate the error. Or at least an option like the one that creates errors for unknown identifers. Unknown commands typed in a windows's editbox would still send these unknown commands to the server.

Then what was all that stuff about /type in your first post?

I don't know how you figure that, but you could do without such comments, they only leave a negative impression.