i’m intermittently jumping into and back out of a custom status bar (this is compiling for z8, not a-machine). while there, also get some input from within the status bar using (get key $).
so far i’ve only checked on macos interpreters but when i use lectrote, gargoyle, and spatterlight, it works perfectly and the status bar reverts immediately back to the standard one when i’m done with it and call (redraw status bar).
but using frotz, the custom status bar doesn’t disappear. the input focus appropriately shifts back to the main window but the status bar just sort of rolls up and off the screen as new text output is generated and pushes it up.
for kicks, i tried dfrotz as well, and it does not go well…
is this a frotz issue that i shouldn’t worry about? is this a dialog compiler issue that is doing something that frotz doesn’t like?
So! Back when the Z-machine was first being implemented, the idea of separate windows that scrolled their contents separately didn’t really exist yet. The way the status bar was implemented in the first interpreters, it was just printed directly onto the top line of the screen. That would immediately be scrolled away when new text came in, which is why on the Z-machine you should always display the status bar right before taking input (and this is actually mandatory in versions 1 through 3).
In fact, when they gave the game control over the status line in version 4, this behavior became required—the way quote boxes are implemented in Trinity, the game expands the status line, prints a quote in it, then resets it back to a single line to show the location heading. The intent is that the quote then remains visible until it gets naturally scrolled away by new text coming in.
Nowadays, we have fancy graphical user interfaces with multiple windows that can scroll independently and overlap each other. But the Z-machine standard specifically and explicitly doesn’t require that: it’s valid to print the status bar onto the top of the screen, eradicating whatever is there, and leave it to be scrolled away over time. Or to just print the status bar every turn alongside the normal text, if you’re a device like a screen reader that can’t go back and overwrite an earlier line. Or not print it at all!
This means that both behaviors you’re seeing are standard-compliant, and interpreters will do whichever is easier on their platform. If you have a big status bar that you need to get rid of, clear the screen afterward—that’s what Inform 6 does when you exit a menu (I6 menus are actually implemented as huge status bars). Or just print the appropriate number of newlines. (Dialog makes this difficult, but it’s doable.)
Oh, right, and the Dialog manual has a warning about this:
It is possible to invoke (status bar $) with different style classes at different times, in order to vary the look of the status area during gameplay. When reducing the size of the top status area (e.g. drawing a status bar of height 1em after having drawn one of height 2em), be aware that some interpreters hide the extraneous lines, while others regard them as being part of the main window.
Unfortunately, it’s not something the author can control. But it’s also generally not a big problem, either.
yeah, i’ve decided not to lose sleep about it. i was just curious because the punyinform talk-menu extension does this and it works perfectly even on frotz and dfrotz. but i just looked at their code and it looks like they’re using inform assembly which probably explains it.