-
Notifications
You must be signed in to change notification settings - Fork 74
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
A little more on line and character events
- Loading branch information
Showing
5 changed files
with
67 additions
and
18 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -18380,15 +18380,55 @@ The different event types, and how to handle them, will be covered in subsequent | |
|
||
> phrase: {ph_glkeventwindow} window of (glk event) ... glk window | ||
> | ||
> Some events take place in or on a given window: for example, commands are typed into windows, so line events have a window, and a mouse event indicates a click or tap on a window. For those events, this returns the window in question; for events not tied to any specific window, such as a screen resize event (affecting every window) or a timer event (nothing to do with the screen), this returns `nothing`. | ||
> Some events take place in or on a given window: for example, commands are typed into windows, so line events have a window, and a mouse event indicates a click or tap on a window. For those events, this returns the window in question; for events not tied to any specific window, such as a timer event, this returns `nothing`. | ||
|
||
## Keyboard input | ||
## Character and line events | ||
|
||
As has already been hinted (see [Dividing the screen into windows]), windows channel text input as well as text output. | ||
As has already been hinted (see [Dividing the screen into windows]), windows channel text input as well as text output. There are times when individual key-presses matter — for example, if the user presses a cursor key to navigate a menu, and we have to react immediately — and then there are times when we don't care what is being typed until an entire command has been entered. That's why there are two different keyboard events: `character event` and `line event`. | ||
|
||
There are times when individual key-presses matter — for example, if the user presses a cursor key to navigate a menu, and we have to react immediately — and then there are times when we don't care what is being typed until an entire command has been entered. That's why there are two different keyboard events: `character event` and `line event`. | ||
* A `character event` is the pressing of a key, or strictly speaking, the input of a character from the keyboard. If the user presses and releases the shift key, for example, that won't generate a character event. Typing the 7 key will do, however, as will typing shift-7, which on most keyboards will lead to a character event with the ``&`` symbol. | ||
|
||
Which ones are sent to the story depends on what the story has asked to receive. In a standard command-parser story, for example, we don't care about the individual keypresses. If the player is typing ``EAT CAKE``, we don't want to receive a stream of character events (E, A, Y, delete, T, space, ...): we just want a line event to say that a complete command has now been typed. | ||
* A `line event` marks when a complete line has been fully typed in, and the user has indicated that it's finished by pressing the RETURN or ENTER key. (That end-marker does not become part of the text of the command.) | ||
|
||
### How to request these events | ||
This comment has been minimized.
Sorry, something went wrong. |
||
|
||
Glk sends us events only if we have requested them. By default, an Inform story never requests character events. Traditionally turn-by-turn command parser stories only care about entire commands, not individual keypresses. If the player is typing ``EAT CAKE``, we don't want to receive a stream of character events (E, A, Y, delete, T, space, ...). | ||
|
||
An Inform story requests a line event only when it has, in effect, halted waiting for a command to be typed in. But since Inform stories usually print quickly and spend most of the time waiting for player input, this means they are almost always requesting line events. | ||
|
||
### Details for these events | ||
|
||
Both character and line events are tied to windows, so `window of (glk event)` can be used to find which. | ||
|
||
> phrase: {ph_glkeventcharactervalue} character value of (glk event) ... unicode character | ||
> | ||
> For a character event, this returns the character in question: for any other event, it returns `U+003F`, that is, the Unicode value for a question mark. | ||
This comment has been minimized.
Sorry, something went wrong.
curiousdannii
Contributor
|
||
|
||
> phrase: {ph_glkeventtextvalue} text value of (glk event) ... text | ||
> | ||
> For a line event, this returns the text of the line. For any other event, it throws a run-time problem. | ||
|
||
### Fictitious character and line events | ||
|
||
Some types of event can be created even though they haven't happened yet, and the two keyboard types are a case in point. It may seem peculiar to create fictitious Glk events, but it turns out be very useful in order to, say, treat mouse clicks as if they were keypresses or commands, as we shall see. Here are the phrases to create such events: | ||
|
||
> phrase: {ph_glkcharacterevent} character event with (unicode character) in (glk window) ... glk event | ||
> | ||
> This produces an event value exactly like that which would have been generated by glk if a key with the given character had been typed in the given window. | ||
> | ||
> The `in (glk window)` can be omitted, in which case the event is in the `main window`. | ||
|
||
> phrase: {ph_glklineevent} line event with (text) in (glk window) ... glk event | ||
> | ||
> This produces an event value exactly like that which would have been generated by glk if the given whole command had been typed in the given window. There's no necessity for the text to be in upper case, or for that matter in lower case. These all produce different events: | ||
> | ||
> line event with "GATHER YE ROSEBUDS" in main window | ||
> line event with "GATHER YE ROSEBUDS" in main window | ||
> line event with "gather ye rosebuds" in main window | ||
> | ||
> Though the Inform command parser would treat all three commands just the same, that all happens much higher up than in this input-output layer. The texts are different, so the events are different. | ||
> | ||
> The `in (glk window)` can be omitted, in which case the event is in the `main window`. | ||
|
||
## Basic IO | ||
|
||
|
If you wanted you could mention the Basic IO phrases
the code of the next pressed key
andprompt the player to enter a line of text
, which request a character and line event respectively. I assume you'll want them to be documented separately though, because they're valid for Z-Machine too.