"num"

ID:260870
 
Jan 26 2010, 10:10 am
I think it would be very nice to see a "num" value for inputs. Num would work exactly how "as num" works. It would allows only for numbers to be put in a input box.

BYOND really should add this, it would make making Applications more feasible. I have never downloaded or bought a program what would let me enter text into a number input so why should BYOND allow this?

Just a idea.

Thanks
Jan 26 2010, 10:13 am
BYOND lacks RegEx support(whatever the heck that is!), so apparently they can't do this.
Jan 26 2010, 10:43 am
In response to Super Saiyan X
Wow, they cant simply give me the option to set it as a num only input box? Also Regex is the Regular Expressions library, from my reading i don't see why they need this to implement a feature we already have with the input statement?

Jan 26 2010, 10:44 am
In response to National Guardsmen
I'm pretty sure alert/input boxes are a default thing.
Jan 26 2010, 11:20 am
This is how <code>as num</code> already behaves.
Jan 26 2010, 11:22 am
National Guardsmen wrote:
I think it would be very nice to see a "num" value for inputs. Num would work exactly how "as num" works. It would allows only for numbers to be put in a input box.

wat

BYOND really should add this, it would make making Applications more feasible. I have never downloaded or bought a program what would let me enter text into a number input so why should BYOND allow this?

having an input box that only accepts numbers is definitely already possible
Jan 26 2010, 12:11 pm (Edited on Jan 26 2010, 12:26 pm)
In response to Zaole
Ok let me make it cleaer what I am talking about. I am talking about a interface input(main.input1) not a input() as num.
Jan 26 2010, 1:11 pm
He means skin input controls, not the input() proc.

I'm pretty sure that if you set the command for the input control to a verb with a number argument, it only allows you to type numbers in.
mob/verb/input_number(n as num)
   src << "You typed in [n]!"
Jan 27 2010, 1:31 am
In response to Kaiochao
Kaiochao wrote:
He means skin input controls, not the input() proc.

See! See! I'm not the only one who makes these mistakes!

I'm pretty sure that if you set the command for the input control to a verb with a number argument, it only allows you to type numbers in.
> mob/verb/input_number(n as num)
>    src << "You typed in [n]!"
>


Which returns:
Sorry, the following is not valid: asdf
usage: test number.

Although, yes, it only allows the sending of numbers, it doesn't do exactly what OP wants, which is only allow the input of numbers (which can be done on an HTML input, btw).

At this moment, there is no way to limit a text box to only allow the input of numbers (that I'm aware of).

So I agree with the feature suggestion of allowing multiple uses for the input control (we already have password, numerical is also a logical inclusion).
Jan 27 2010, 11:57 am
In response to Tiberath
Tiberath wrote:
So I agree with the feature suggestion of allowing multiple uses for the input control (we already have password, numerical is also a logical inclusion).

That's how i thought about it too. Whats the chances of this being added anytime soon tho, or if ever? Wouldn't it be simple for Tom or Lummox to add this?
Jan 27 2010, 9:11 pm
In response to Tiberath
Tiberath wrote:
So I agree with the feature suggestion of allowing multiple uses for the input control (we already have password, numerical is also a logical inclusion).

I further extend this feature suggestion into a much more general case. Consider first Qt, one of the most elegant GUI toolkits I've ever used. Qt's QLineEdit widget has a setValidator() method which takes a QValidator object. QValidator is an abstract class whose functionality is implemented in its children; i.e. QIntValidator, QDoubleValidator, and QRegExpValidator, though the user can freely define any other kind of validator.

All translated to DM---and with an example validator---this might look something like:
input_validator
    proc
        Validate(t)
            return 1
            
        Fixup(t)
            return t
    
    int_validator
        var
            floor = null
            ceil = null
            
        Validate(t)
            if(t)
                t = text2num(t)
                if(t != round(t))
                    return 0
                else if(!isnull(floor) && floor>t)
                    return 0
                else if(!isnull(ceil) && ceil<t)
                    return 0
                else
                    return 1
        
        proc
            SetRange(bottom, top)
                if(isnum(bottom))
                    if(isnum(top))
                        if(bottom <= top)
                            floor = bottom
                            ceil = top
                        else
                            CRASH("In SetRange(a,b), a must not be larger than b. Given SetRange([bottom],[top])")
                    else
                        // Don't crash because SetRange(a, null) may be desirable.
                        floor = bottom
                        ceil = null
                else if(isnum(top))
                    floor = null
                    ceil = top
                else
                    floor = null
                    ceil = null

For more information on the Fixup() proc, see Qt's description of it. The main idea is that the validator could use it before trying to validate the input to try and make the text valid; i.e. for a phone number validator, you might have it strip out all '(', ')', ' ', '.', and '-' characters, and Validate() could simply test if there were consecutive numeric digits knowing that formatting details have already been accounted for.

With this kind of flexibility, validators could be written to test input against regular expressions, and generally anything else. Then a simple way to connect it to the existing structure of input controls would be something like:
proc/set_validator(player, control, input_validator/v)
   winset(player, control, "validator=\ref[v]")


I would wholly support a feature like this being implemented. It is potentially a bit more work but, in the long run, it prevents the need for the devs to have to keep cranking out new GUI features every time someone has a request to have some new kind of input validation; say, the number input requested here, to one that only accepts integers, to one that doesn't accept negative numbers, etc.

An alternative to all of this would be for input controls to have a regular expression string which could be set with winset(). The problem with that, though, is that regular expressions don't really exist in the BYOND codebase as far as I'm aware, and there are already several regular expressions libraries available for someone to implement a regexp_validator given my proposed input_validator feature.

Though, if Tommux decided to start building in a regular expression library for the GUI, I certainly wouldn't mind them adding some internal regex procs to do the work in place of user libraries. :]