+_canadianbacon_ Posted February 16, 2008 Share Posted February 16, 2008 Is there a variable scope when using an Input defined to save the value to a variable? My first attempt to get a user input, then modify an items description of based on the input always returned the variable with its original value. i.e. GetInputzinputPName Set zitemTestItem.Description equal to PName Results in the description of the item not changing. I did find if I handle the work in the inputs value change event, it was fine (though not obvious from a code readability standpoint). Is the variable in a global scope? Should it be set with the new value once the input finishes? Quote Link to comment
Ranger Fox Posted February 18, 2008 Share Posted February 18, 2008 I, too, thought it was global scope, but had that same problem. I bet it has something to do with the way flow is handled in real-time. For instance, after the input change event and current event control have fired, the input's value will be accessible in the variable to which you assigned it. I'm not certain about that, though, as I haven't tried it. Mere speculation. Quote Link to comment
+frigschneck Posted February 25, 2008 Share Posted February 25, 2008 What you have to learn (and what confused me a lot) is that generally (I assume; at least for message boxes and inputs) the software doesn't wait for any user input (also clicking an "ok" button is an user input), it just spawns the screen and then continues with whatever code follows until the end of the function, without waiting for the user to react to the screen (*). If you want to react to an user input, you have to write a function for the corresponding event which is fired once the user clicked a button (or finished an input). For buttons, you have to add a button script (reachable at the page where you define the buttons). For user inputs, which was your original question, you have to write code for the corresponding user input event (accessible from the builder main window as "inputs"). (*) consequently, if you open (or switch to) another screen in the following code, the screen waiting for user input will be hidden (and not visible to the player, unless he has a very fast eye). Quote Link to comment
Ranger Fox Posted February 25, 2008 Share Posted February 25, 2008 That's correct, frigschneck. The way I understood it from a Groundspeak post was that the code continues executing in real-time and does not/cannot wait for input. I think the reason behind this, my own guess, is so it can keep track of where the player is. Quote Link to comment
+twolpert Posted February 26, 2008 Share Posted February 26, 2008 OK, folks, this is twisted . Previous posts regarding real-time flow of control appear to be correct. However, there is an additional twist you should know about. The input variable IS global in scope. However, its value never gets set unless there IS script attached to the input event. If you don't need to do anything else when the event fires, you can leave the script empty. But the function must be defined (the event must show up as bold in the builder). To test this, create an input with an associated variable. Omit the input event script. Run the cartridge in the emulator and do whatever is necessary to request the input. Complete the input. Switch to the debugger and print the variable. No matter how long you wait, it will always have its initial value -- not the user's input. Now, repeat the test but attach an empty script to the input event. Now you will find that the variable contains the user's input value. You still have to be careful about the flow of control issues. But you CAN reference the variable value later. Fun and games. Tom Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.