Telnet Input

About Telnet Input

ID:109994

Feb 18 2011, 10:00 pm

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.

Feb 23 2011, 9:38 pm (Edited on Feb 23 2011, 9:47 pm)
Keeth	The library has debug mode enabled by default, for some reason. Had to go into "Build -> Preferences for telnet_input -> uncheck debug option" to get it to go away. There also seems to be a problem with your demo setup. It's including demo #2 automatically (when run by itself) regardless of whether or not you want it to be included. Have to remove it from the DME file manually.

Feb 26 2011, 2:12 am

Alathon

Keeth wrote:

The library has debug mode enabled by default, for some reason. Had to go into "Build -> Preferences for telnet_input -> uncheck debug option" to get it to go away.

There also seems to be a problem with your demo setup. It's including demo #2 automatically (when run by itself) regardless of whether or not you want it to be included. Have to remove it from the DME file manually.

Thanks - I'll check those issues out right away.

Mar 1 2011, 4:12 pm

Keeth

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.

Mar 3 2011, 12:09 am (Edited on Mar 3 2011, 12:42 am)

Alathon

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.

Mar 3 2011, 8:17 am

Alathon

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

Mar 4 2011, 9:50 pm

Keeth

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.

Mar 10 2011, 1:56 pm (Edited on Mar 11 2011, 10:24 am)

Keeth

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.