What to do about "Fatal Error: Printing text to a window that is waiting for line or character input is not allowed" when waiting for a keypress

Authoring Inform 7
1

I have some “wait for any key” lines, and I noticed that, in the Windows IDE, if I resize the window while it’s waiting for a keypress, it can cause this message:

Fatal Error: Printing text to a window that is waiting for line or character input is not allowed.

This looks similar to the issue discussed in this thread.

My question is, what are authors supposed to do about this? Are we supposed to always put a paragraph break before a “wait for any key”? Or is this something that can be ignored? The “fatal error” message doesn’t seem to show up in Lectrote or Windows Glulxe.

2

One possible cause of this is if the “redraw the status window” code (which runs when the window is resized) accidentally prints text to the main window. Are you doing something special in the status window?

Are we supposed to always put a paragraph break before a “wait for any key”?

That doesn’t matter for this.

The “fatal error” message doesn’t seem to show up in Lectrote or Windows Glulxe.

Lectrote/Quixe is generally the most persnickety about these errors, so if it only shows up in the IDE, it be an IDE bug.

3

Looking back at the thread… I see the paragraph break does matter for some cases, but only because it clears a flag in Inform’s baroque printing system.

If you’re running rulebooks or activities in the status-line printing code, you may need I6 code similar to what Dannii posted here.

4

I have only one line of code that mentions the status line. It’s set up like this:

now the right hand status line is "[if condition]Text[otherwise if condition]Text[otherwise if condition]Text[end if]".

Is that a problem?

5

No, that’s very unlikely to be the problem.

Which version of I7 are you using?
Which extensions?
Any custom Glk event handling code?

6

Well, the error message goes away (for this keypress, at least–haven’t tested all of them) if I add a paragraph break right before “Wait for any key.”

6M62

Here are the ones listed in response to VERSION, but maybe there are more that are hidden by “authorial modesty”:

Object Response Tests version 7 by Juhana Leinonen
Menus version 2/141228 by Wade Clarke
Numbered Disambiguation Choices version 7/140501 by Aaron Reed
In-Line Topical Hints version 1/150129 by Andrew Schultz

Ok, there’s also this that does not show up in response to the version command:

Include version 10 of Glulx Entry Points by Emily Short.

And the Menus extension includes Basic Screen Effects.

Yes, I’ve got sounds, sound notifications, and timer events, but at the time of this keypress (which is before the first turn), there aren’t any sounds or timers going on, I don’t think.

7

If adding a paragraph break fixes it, and you’re happy with that, then that’s probably a good solution.

Otherwise you’d need to dig into the extensions and see if their event handling code needs to be updated to better opt out of Inform’s arcane paragraphing system.

For reference, the current code (recently merged into the Inform core itself) for handling events is

	! Run the glk event handling rules (but disable rules debugging because it crashes if keyboard input events are pending)
	@push debug_rules; @push say__p; @push say__pc;
	debug_rules = false; ClearParagraphing(1);
	FollowRulebook(GLK_EVENT_HANDLING_RB, Glk_Event_Struct_type, true);
	@pull say__pc; @pull say__p; @pull debug_rules;