input() and skin elements

ID:260628
 
Sep 5 2008, 7:25 am (Edited on Sep 5 2008, 7:30 am)
Is it at all possible for prompts created from input() to have some manner of non-empty element name?

I ask because I recently implemented a datum to handle some inputs for me, its primary function to delete itself and close the input if the client doesn't do anything with it for an extended period of time. I ended up going this route after, apparently, some ne'er-do-well decided to log on a bunch of keys, open an input on each, and proceed to go AFK for several hours.

I was checking if any element on the skin has focus, but that route proved not to work after I discovered inputs have no id at all, not to mention I can think of other ways an empty string could be returned and again render the check subject to error.

It's not a particularly critical issue, since I can imagine an input doesn't suck up too much just sitting idle on the client's end, though I would like to clean up the intentionally ignored prompts and end the executing proc in these cases.

Also, keystrokes resetting client.inactivity would be nice.
Oct 1 2008, 5:47 am
Mobius Evalon wrote:
Is it at all possible for prompts created from input() to have some manner of non-empty element name?

Not as such, since input() and alert() prompts aren't part of the skin proper.

I ask because I recently implemented a datum to handle some inputs for me, its primary function to delete itself and close the input if the client doesn't do anything with it for an extended period of time. I ended up going this route after, apparently, some ne'er-do-well decided to log on a bunch of keys, open an input on each, and proceed to go AFK for several hours.

The best way to clear that up is with a datum. There's a very old thread that discusses how to use a timer to close an input/alert box; it basically boils down to this:

1) Create a datum that will send the alert/input for you on New(), and give it a time to expire; spawn a del(src) call for that time.
2) Create a callback function and have the datum call it whenever the input is received or the timer expires, or poll the datum every tick until it's deleted or the result is in.

When the datum is deleted, the input() or alert() associated with it will also be canceled. The result looks something like this:

timedinput
  var/result
  var/done

  New(text, title, choices, default_choice, time=600)
    spawn(time) del(src)
    CreateInput(text, title, choices, default_choice)

  // override this for /timedinput/asnum, /timedinput/astext, etc.
  proc/CreateInput(text, title, choices, default_choice)
    result = input(text, title, default_choice) as null|anything in choices
    done = 1

proc/tinput(text, title, choices, default_choice, time, intype=/timedinput)
  var/timedinput/T = new timedinput(text, title, choices, default_choice, time)
  while(T && !T.done) sleep(1)
  return (T && T.result)


The alternative method of course is to create an input window of your own and clone that as needed, which would likely also entail using a datum.

Lummox JR
Oct 1 2008, 10:49 am
In response to Lummox JR
The alternative method of course is to create an input window of your own and clone that as needed, which would likely also entail using a datum.

I have my own skin alerts library (which I'll improve a bit sooner or later) and I plan on making a skin input library when 430.1000 is released!
Oct 1 2008, 12:51 pm
In response to Jeff8500
That'll be something to look forward to. I was thinking of that too since interface inputs would allow a much more flexibility than HTML/JavaScript. The only thing that threw me off was the customization. I was thinking of having a parameter formatted text string sent to the proc that triggers the input and each parameter stands for the color of each control used in the input.

Mobius Evalon wrote:
Also, keystrokes resetting client.inactivity would be nice.

Doesn't that already work?
Oct 1 2008, 2:33 pm
In response to Kakashi24142
Kakashi24142 wrote:
That'll be something to look forward to. I was thinking of that too since interface inputs would allow a much more flexibility than HTML/JavaScript. The only thing that threw me off was the customization. I was thinking of having a parameter formatted text string sent to the proc that triggers the input and each parameter stands for the color of each control used in the input.

Mobius Evalon wrote:
Also, keystrokes resetting client.inactivity would be nice.

Doesn't that already work?

No, if you send something via an input control, then it resets client.inactivity. (I think that's how it works.)