Telnet Input

by Alathon
Gather input from telnet clients [More]
To download this library for your Linux/Mac installation, enter this on your command line:

DreamDownload byond://Alathon.telnet_input##version=8

Emulator users, in the BYOND pager go to File | Open Location and enter this URL:

byond://Alathon.telnet_input##version=8

172 downloads
Version v1.0
Date added: Feb 18 2011
Last updated: Mar 9 2011
1 fan
The regular input() procedure is ineffective, if you want to query telnet players. Because of how it works, you risk situations where input slips through the cracks and goes to client/Command() instead.

This library attempts to remedy that by providing an Input object that serves the same purpose. To keep the API clean and simple, the object can do a whole lot more than input() - It can sanitize and reject/re-query for input, based on many different criteria.

There is currently no documentation, that will be fixed as soon as possible. The demo.dm file contains some usecases.

Comments

Keeth: (Mar 10 2011, 1:56 pm)
I'm going to rephrase this error, since I discussed it with Alathon and figured out the issue. Basically, there is no way to break out of an input that asks for confirmation until the confirmation is requested. In a normal input, we would simply return null and handle the input in whatever block called the input. But for confirmations, we have to wait until they enter the command a second time before we can get access to it.

So, we need a way to end the input from the callback itself.
Keeth: (Mar 4 2011, 9:50 pm)
There is a small problem with confirmation errors not being displayed properly. I believe this is the cause:
        __parseInput(n)
            var/inputError/E = __parser.parse(src, n)
            if(!istype(E, /inputError) && __callback)
                if(__callback_obj)
                    E = call(__callback_obj, __callback)(__target, __input, src)
                else
                    E = call(__callback)(__target, __input, src)

            if(!istype(E, /inputError))
                if(__confirmQuestion && !__confirm)
                    if(!cmptextEx(__input,__confirmWith))
                        E = inputOps.getError(inputOps.ERROR_CONF) // this doesn't appear to be correct. should be:
                        E = inputOps.getError(src, inputOps.ERROR_CONF)  // should be replaced with this

            if(istype(E, /inputError))
                __state = inputOps.STATE_ERROR
                __error = E

            else
                __state = inputOps.STATE_DONE


I'd also like it if you would add a shortcut for /inputError/New(), where if only one argument is provided, it is set to the message rather than the trigger. I'd rather not have to supply null as the first argument when I'm creating "non-standard" errors. I do this a lot in the callbacks for some inputs.
Alathon: (Mar 3 2011, 8:17 am)
I've uploaded a test implementation of the new way of handling errors.

The /inputError object is now responsible for generating an error message, through a procedure where it recieves the client and Input object as input. This allows you to customize an error to the user.

You can check out the relevant changes in inputParser.dm, inputFormatter.dm, inputError.dm and input.dm.

Things really need documentation now. demo.dm includes an example of how to do per-Input overriding of existing messages, by overriding the 'notnum' error with a new /inputError object.

There may be things I didn't test that don't work any more, or other issues I haven't foreseen. However, things should generally be the same. Please test things out
Alathon: (Mar 3 2011, 12:09 am)
Keeth wrote:
I'd like a little bit more control over the errors and such that the library sends. Preferably, there would be a way to set which error messages should be used for which cases, or if one should be used at all. I'd like, for example, no error message to be presented when blank input is given in most cases, just resending the question. I'd also like to change the messages sent when the confirmation is wrong.
This can probably be extended to all error messages.

Preferably these would work uniquely per Input object.

What do you mean with this? You want per-input specific error messages on invalid input?

I suppose I can see how that'd be useful. I'm going to have to rewrite the error handling. My idea is as follows:

An /inputError object will return an 'error code', which is just a string. The /Input object will then turn this string into an error message by first searching through its own list of error codes (Which you can supply it with, empty by default), and then inputOps' list of error codes (For the default parsers).

I'll see about implementing this as soon as possible. The change will only supplement with a few new functions, the API will remain the exact same otherwise.
Keeth: (Mar 1 2011, 4:12 pm)
I'd like a little bit more control over the errors and such that the library sends. Preferably, there would be a way to set which error messages should be used for which cases, or if one should be used at all. I'd like, for example, no error message to be presented when blank input is given in most cases, just resending the question. I'd also like to change the messages sent when the confirmation is wrong.

This can probably be extended to all error messages.

Preferably these would work uniquely per Input object.