Some interface suggestions

ID:132715
 
Dec 12 2009, 8:57 am (Edited on Dec 12 2009, 9:05 am)
I'm not sure if this is intentional or not, but right now you can only select text in an input control using the mouse, even with the directional macros removed. In most text boxes, you can select text by holding the shift key and then pressing one of the arrow keys. Would this be possible to add for BYOND skins?

Also, input controls are annoying in how they handle double quotes. Right now, the best option (other than maybe using client/Command or browser interfaces) for input controls that execute one specific verb is to set the input's command property to something like say . The problem with this is that if the player hits the space bar right away, then a double quote appears at the start of the text box instead of a space. If the first character typed is a double quote, then if another double quote ever appears, then spaces typed by the user are filtered out by BYOND and when they hit enter, the say verb won't be called but instead be replaced by a 'Sorry, the following is not valid' error. Setting the control's command parameter to say " will fix the first problem, but cause any double quotes with at all with text after them to trigger an error. Finally, using the no-command property might fix this entirely, but then the user can't hit enter to submit the text (if a macro has been set for the enter key, it isn't run when an input control has focus).

One more request: could Click() and DblClick() be called for a couple controls other than maps, grids, and statpanels? Specifically, it would be nice to be able to close a tab when the user middle clicks it.
Dec 13 2009, 9:18 am
Nickr5 wrote:
Also, input controls are annoying in how they handle double quotes.

It's not quite the input controls themselves.

The problem with this is that if the player hits the space bar right away, then a double quote appears at the start of the text box instead of a space. If the first character typed is a double quote, then if another double quote ever appears, then spaces typed by the user are filtered out by BYOND and when they hit enter, the say verb won't be called but instead be replaced by a 'Sorry, the following is not valid' error.

Ah, thing is, those are all not problems, on the contrary. That's simply how text arguments work in commands; they have to be designated as text, or DS has no way to know that they're meant to be text.
What you want here just isn't an argument using the text input type, which, like most other input types, is specially parsed from the command into a value. In this case you wants to freely let the player type whatever he wants, with no parsing or special handling; this is what the command_text input type for. An argument using it just directly receives all the command text (surprise) given once it's reached, without any parsing.

One more request: could Click() and DblClick() be called for a couple controls other than maps, grids, and statpanels? Specifically, it would be nice to be able to close a tab when the user middle clicks it.

Note that no interface control can be clicked at the moment (although in some HTML-supporting controls, you utilize a hyperlink and Topic()). Only atoms themselves can be clicked.
The mouse procs are currently atom-exclusive and have atom-based versions; it would be best to implement interface mouse control separately (if it would even be through procs), keeping the current mouse procs' nature as it is. This separation would not only will keep the behavior of old code intact and unbroken, but be generally more efficient and more convenient most of the time.
Dec 13 2009, 9:40 am
In response to Kaioken
Kaioken wrote:
DS has no way to know that they're meant to be text.
That's the problem - there's no way to turn this behavior off and still be able to send the contents of an input control as an argument to a verb.

In this case you wants to freely let the player type whatever he wants, with no parsing or special handling; this is what the command_text input type for. An argument using it just directly receives all the command text (surprise) given once it's reached, without any parsing.
I've been using the command_text type, however in this case the input control itself doesn't know what type the argument is and still performs the parsing because it expects each argument to the verb may be between double quotes. Using command_text just stops BYOND from looking for text macros.
Dec 13 2009, 9:49 am (Edited on Dec 13 2009, 10:00 am)
In response to Nickr5
If a verb's first argument has a command_text input type, no parsing at all is done on a command referring to that verb (other than isolating the verb name from the argument). The same for typing restrictions and as such on the command line (which are input-type-dependent).
I just tested it myself, and it works as expected, no matter how many spaces/quotes/symbols you stuff into the command line and as such. Perhaps you should show the declaration of your verb to see if any of your argument setups are somehow interfering.
Dec 13 2009, 9:57 am
In response to Kaioken
 
client
    verb
        Say(msg as command_text)
            alert(src, "Say called")


If the first character typed is a double quote, then if another double quote ever appears, then spaces typed by the user are filtered out by BYOND and when they hit enter, the say verb won't be called but instead be replaced by a 'Sorry, the following is not valid' error.

Try typing "a" b into the input control with its command set to Say , the verb isn't being called at all for me (I get a "Sorry, the following is not valid: b
usage: Say command" error), and you can't type spaces after the 'b'.
Dec 13 2009, 10:05 am (Edited on Dec 13 2009, 10:20 am)
In response to Nickr5
Ah. That is really a bug, as the interpreter gets confused if you start the command with what seems like a text string argument, ignoring that this verb's first argument is marked to be taken as raw command text instead of being interpreted. It thinks that the psuedo-text-string is the entire first argument, so since you have some stuff after it, it complains that you have too many args. You know this certainly shouldn't be the case as there is no problem if you start with what seems like an isolated atom or number argument instead.

Because this bug occurs since the interpreter thinks you're giving too many arguments, you can actually workaround it until it's fixed by declaring more (optional) arguments:
client/verb/cmd(a as command_text,b as null|command_text)
   src << a

This will correctly accept the command cmd "x" bla, as although DS thinks you give a second argument, there is actually one (whose type fits), so it doesn't give an invalid command error. This won't accept "more" args though, like cmd "a" "b" "c", so you'd need to use many arguments for a complete workaround (not particularly a problem, just autogenerate the code).

In my previous testing, I happened to have tried other examples, such as [verb name] 123"abc" "xyz" asfasf qwe8ru"saf" "fasdf" z"z, which do work fine. Also, the text string notation of skipping the closing quote also doesn't cause this issue, as the interpreter isn't confused by the argument being seemingly closed.