"as key" verb argument

ID:700747
 
Apr 24 2012, 5:02 am (Edited on Apr 24 2012, 5:07 am)
BYOND Version:493
Operating System:Windows Vista Home Basic
Web Browser:Firefox 11.0
Applies to:DM Language
Status: Verified
A member of our crack team of bug testers has verified that this issue is reproducible, and has handed it off to the development team for investigation.
Descriptive Problem Summary:
Cannot interact with data obtained using the "as key" verb argument. Data is being stored inside the "alt" variable but I cannot seem to manipulate it in any way I can think of.

Numbered Steps to Reproduce Problem:
1) use the code below
2) run the verb
3) select one of your usernames
3) await your selected username to be printed to your skin's output.

Code Snippet (if applicable) to Reproduce Problem:
/client/verb/sendalts2()
    var/alt = input(usr,"Alts","Alts",null) as key|null
    usr << "[alt]"


Expected Results:
An input message should display a list of keys from the usr's key.txt in their BYOND folder. The selected key should then be output to the usr.

Actual Results:
The input list shows. However, when one is selected nothing happens. Also when checking alt's type using isnull, istext, ispath, isnum, isfile etc. No information was returned at all. So I'm assuming it's some weird datatype or something.
if(isnull(alt)) world << "null" does nothing, so there -is- data being stored in alt. I just can't interact with it in any way.

Does the problem occur:
Every time? Or how often? Everytime
In other games? Isolated in a test environment. Language defect/(feature?)
In other user accounts? yes
On other computers? yes

When does the problem NOT occur? Unknown

Workarounds: None that I am aware of.

Notes: I may just be misguided as to the value being returned by the input list. Or, this may have only be intended as a client-side thing. Regardless, any information would be appreciated.

http://www.byond.com/forum/?post=700728
http://www.byond.com/forum/?post=162647

Thanks

Apr 24 2012, 6:02 am
You're actually a bit off as to what the real problem is. I did some experimenting with this a couple of years back, and it's not that you can't interact with the return value it's that the input() isn't actually returning control to the proc, it's just hanging.

Try the following:

client/verb/sendalts2()
    world << "In sendalts2"
    var/alt = Query()
    world << "After query"
    world << "Alt: [alt]"


client/proc/Query()
    world << "In query"
    var/alt = input(usr,"Alts","Alts",null) as key|null
    world << "After input"
    return alt


You'll notice that all you get is "In sendalts2" followed by "In query", selecting a key doesn't display "After input" or "After query", so it's simply hanging.
Apr 24 2012, 6:05 am
One relevant fact to keep in mind is that your snippet is not using "as key" in a verb argument, but an input(), and there's a difference. I'm not sure that input() was meant to handle this at all.
Apr 24 2012, 6:12 am
Along those lines, it's worth noting that when you do use it as a verb argument it doesn't actually bother executing the verb to a notable level. It pops up the input, but it never executes anything within and the verb doesn't even show up in the profiler.
Apr 24 2012, 6:19 am
Even if you use it in as an argument in a verb, nothing will not be returned. So, if what Audeuro is saying is the case, it's just borked.

and after testing what Aud said, he's correct. The proc just sleeps.
After you use something simple like
        keyinput()
            world << input(usr) as key
//or
        keyverb(x as key)
            world << x

and then run ".debug status" in the command prompt, you'll get:

Sleeping procs:
/mob/verb/keyinput

Apr 24 2012, 8:13 am
Thanks for the fast responses.
May 14 2014, 1:49 pm
Stephen001 changed status to 'Verified'
May 14 2014, 1:50 pm
I've decided to consider this a valid bug, not for the input() part, for the verb argument part, which I've replicated on 506.1246
May 14 2014, 5:45 pm
Thankyou, please credit Audeuro if it's not too much trouble, since my original report doesn't really have much to do with the actual problem.