Forums Feature Suggestions Treating Manually Entered Commands Differently.

mIRC already shows some limited ability in remembering if a command was executed by script, or if a command was entered by hand... and sometimes remembers what window it was entered in. For instance, mIRC will remember what window a user typed the [color:660000]/WHOIS <Nickname>[/color] command, and it will display the WHOIS information in that window only. If executed by script, the WHOIS info is dumped to the Status Window.

I propose that some unified system of remembering whether a command was called by Event Script, or was called by Editbox Input, and to handle each differently. More likely than not, the user would be uninterested in seeing the results of an event initiated command in their active display, but would like to see the results if they manually typed that same command. For instance...

If a user types (by hand) [color:660000]/CTCP <Nickname> <Command> <Parameters>[/color], mIRC should try to remember the Nickname and Command so it can display the results in the [Active] Window the request was entered in. If the same CTCP request were performed via Event Script, the results ought to be displayed in the Status Window only. Presently, we're stuck with ALL CTCP Replies going to Status or Active Window, Only.

If a user types [color:660000]/DNS <Nickname or Address>[/color] then the results of the DNS ought to be displayed in the Active Window, otherwise it should be displayed in the Status Window. This is the behavior most people expect from an IRC client, and indeed this is how most IRC clients behave.

I understand for Khaled to impliment such a system would require smart remembering (queuing) and anticipation of commands inputted by the user which are expected to produce a response. It would probably mean special coding for almost every command that generates a reply.

Anyway, just an idea.

- Raccoon

Wouldn't this create a memory leak if the reponse never came?

I suppose such a queue could have a timeout, expiring old entries instead of waiting indefinitely.

Isn't this the job of the script authors? There are times, such as when you are debugging, need to see the output. And this really isn’t hard to code. You have the on input event, so you know when something is manualky entered. My script, for example, sends userhost commands constantly to refresh the status of users in channels. It keeps track by using a hash table which ones to block and which ones don’t.