Clearing input window & disabling command history

Is there a way to clear text that the player has typed into the input window but hasn’t yet entered? I’ve been looking around at the likely extensions (e.g., “Text Input-Output Control,” “Flexible Windows,” etc) & their source code, but haven’t come up with a way.

The other thing I’m wondering is if there is an easy way to disable the command history that the player can access using the the up-arrow key? I was looking at the “Interactive Parser” extension source code and figure I could borrow from Jon Ingold’s method of replacing the Keyboard Primitive–but I’m hoping there’s an easier way.

Thanks for any help!
Ethan

Could you clarify a couple of things?

I take it that you are using separate windows for text input and output?
Are you wanting to clear partial input in response to a real-time event, or in response to a specific keypress, or…?

The up/down arrow behavior is controlled by the interpreter, so the only way to get control is indeed to replace KeyboardPrimitive(), as Jon does with Interactive Parser. If the game is for a gallery piece (or any other situation where you control the computer on which it is displayed), I suppose that it might also be possible to disable the up/down arrow keys at the OS level.

–Erik

I’m not using a separate window for the user input… It’s just the regular command line. The way I have it set up is that if there is no user input within a time period (say, 2 minutes), the game restarts via:

follow the immediately restart the VM rule

The problem is that if the last person to use the keyboard left something unentered on the command line, it gets carried over to the game start screen. This is a bit of an edge case, and it isn’t the end of the world if this behavior remains–but it would be nice to have it behave a bit cleaner.

I like your suggestion of remapping/disabling the arrow keys on the OS level. I’m going to have to do that for the ESC key as well so that gallery-goers don’t inadvertently exit the game.

This is another situation where the behavior is in the hands of the interpreter rather than the game. Which interpreter are you using? I would think this would be a good thing to report to the author, as the restart opcode ought to result in the clearing of any input buffers.

Anyway, if you are compiling to Glulx, you should be able to prevent this from happening by canceling the line event manually before restarting. If you’re not already using Flexible Windows, you can do this:

[code]To cancel line input in main window: (- glk_cancel_line_event(gg_mainwin); -)

To restart:
cancel line input in main window;
follow the immediately restart the VM rule.[/code]

If you are using Flexible Windows, there is a phrase already defined which you can find in the documentation.

Hopefully, this works…

–Erik

Does clearing the screen (via Basic Screen Effects) just before following the immediatley restart the VM rule work?

Is this a Z-machine game or Glulx? What interpreter are you using?

In Z-code, I think that triggering a timed event during line input, and then doing a VM @restart, should clear the input line. For Glulx, this is definitely true. But it’s probably not a case that anybody has ever tested.

If you’re in Z-code, it occurs to me, you might be trying to do the restart in a timer routine without actually interrupting the input event. That would be a mistake.

But how you’d fix it depends on what your code looks like.

The behavior I was describing was showing up using the interpreter that accompanies the Inform7 development environment… I’ve been experimenting with various interpreters to figure out which one to use (the game I’m developing is supposed to be shown in a kiosk-like mode) and I’ve run into bigger problems than the left-over history, so I’m putting that on the back burner for the moment :slight_smile: