the InputDef object for the input in progress

flag: keystroke/event input is in progress

Flag: command line input is in progress. If this is set, it means that we interrupted command-line editing by a timeout, so we should not show a prompt the next time we go back to the keyboard for input.

Flag: inputLine does not support timeouts on the current platform. We set this when we get an InEvtNoTimeout return code from inputLineTimeout, so that we'll know not to try calling again with a timeout. This applies to the current interpreter only, so we must ignore any value restored from a previously saved game, since the game might have been saved on a different platform.

Note that if this value is nil, it means only that we've never seen an InEvtNoTimeout return code from inputLineEvent - it does NOT mean that timeouts are supported locally.

We assume that the input functions are uniform in their treatment of timeouts; that is, we assume that if inputLineTimeout supports timeout, then so does inputEvent, and that if one doesn't support timeout, the other won't either.

Cancel input in progress.

If 'reset' is true, we'll clear any input state saved from the interrupted in-progress editing session; otherwise, we'll retain the saved editing state for restoration on the next input.

This MUST be called before calling tadsSay(). Games should generally never call tadsSay() directly (call the library function say() instead), so in most cases authors will not need to worry about calling this on output.

This MUST ALSO be called before performing any keyboard input. Callers using inputManager methods for keyboard operations won't have to worry about this, because the inputManager methods call this routine when necessary.

receive post-restore notification

Read an event, processing real-time events while waiting, if desired. 'allowRealTime' and 'promptFunc' work the same way they do with getInputLine().

Read an event or keystroke. 'allowRealTime' and 'promptFunc' work the same way they do in getInputLine(). If 'keyOnly' is true, then we're only interested in keystroke events, and we'll ignore any other events entered.

Note that this routine is not generally called directly; callers should usually call the convenience routines getKey() or getEvent(), as needed.

Ask for input through a dialog. Freezes the real-time clock for the duration of the dialog display. The arguments are the same as for the built-in inputDialog() function.

Ask for an input file. Freezes the real-time event clock for the duration of reading the event.

Read a line of input from the keyboard.

If allowRealTime is true, we'll execute any real-time events that are already due to run, and then we'll allow the input to be interrupted by real-time events, if interrupted input is supported on the local platform. Otherwise, we will not process any real-time events.

promptFunc is a callback function to invoke to display the prompt. This is provided as a callback so that we can re-display the prompt as necessary after real-time event interruptions. Note that if real-time interruption is not to be allowed, the caller can simply display the prompt before calling this routine rather than passing in a prompt callback, if desired.

If we're in HTML mode, this will switch into the 'tads-input' font while reading the line, so this routine should be used wherever possible rather than calling inputLine() or inputLineTimeout() directly.

Read a line of input from the keyboard - extended interface, using the InputDef object to define the input parameters. 'defObj' is an instance of class InputDef, defining how we're to handle the input.

Read a keystroke, processing real-time events while waiting, if desired. 'allowRealTime' and 'promptFunc' work the same way they do with getInputLine().

Begin generic input. Cancels command report list capture, and shows the prompt if given.

Begin reading key/event input. We'll cancel any report gatherer so that prompt text shows immediately, and show the prompt if desired.

End keystroke/event input.

Begin command line editing. If we're in HTML mode, we'll show the appropriate codes to establish the input font.

End command line editing. If we're in HTML mode, we'll show the appropriate codes to close the input font.

Pause for a MORE prompt. If freezeRealTime is true, we'll stop the real-time clock; otherwise we'll let it keep running. Even if we don't freeze the clock, we won't actually process any real-time events while waiting: the point of the MORE prompt is to allow the player to read and acknowledge the on-screen display before showing anything new, so we don't want to allow any output to result from real-time events that occur while waiting for user input. If any real-time events come due while we're waiting, we'll process them when we're done.

In order to ensure that the display makes sense to the user, we flush any captured input in the transcript before pausing. We re-activate transcript capture after the pause if it was active before. Note that in some cases, this could affect the overall output for the command, since some commands wait until the very end of the command to go back and process the entire transcript for the command. Since we interrupt the transcript, flushing any output that occurred before the pause, a command that goes back over its entire output stream at the end of the turn won't be able to see or modify any of the output that occurred prior to the pause, since we will have flushed the output to that point.

Process any real-time events that are ready to run, and return the timeout until the next real-time event.

If allowRealTime is nil, we won't process real-time events at all; we'll merely return nil for the timeout to indicate to the caller that any user input interaction about to be attempted should wait indefinitely.