I’m experiencing an issue where the bottom row in a side grid window is getting cut off (depending on the precise sizing of the Lectrote window.)
Here is code that shows it for me.
"Height" by Arthur DiBianca
Include Basic Screen Effects by Emily Short.
Include Flexible Windows by Jon Ingold.
when play begins:
open sidewin;
Use no status line.
Table of User Styles (continued)
window style name reversed
sidewin all-styles false
the sidewin is a text grid g-window spawned by the main window.
the position of sidewin is g-placeright.
the scale method of sidewin is g-fixed-size.
the measurement of sidewin is 10.
to setcursor row (R - a number) col (C - a number):
[corrects a bug in Flexible Windows 15/210811]
set sidewin cursor to row C column R;
rule for refreshing sidewin:
repeat with R running from 1 to height of sidewin:
setcursor row R col 1;
say "[R]";
every turn:
refresh sidewin;
Cave is a room. "The window height is [height of sidewin].".
player is in Cave.
This was in 6L38. (I also tried to compile it in 10.1.2, but I got confused about how to do the window extension stuff.)
I put this together using in 6M62, using the extensions in GitHub - i7/extensions at 9.3 . With those, I didn’t need the “setcursor” phrase – I guess that bug was fixed? I currently have this:
rule for refreshing sidewin:
let H be height of sidewin;
repeat with R running from 1 to H:
[setcursor row R col 1;]
set sidewin cursor to row R column 1;
say "[R][if R is H]*[end if]";
The point of using H is just to draw a * on the last line, thus making it easier to see which line is the last line.
With that, everything seems to work correctly in Gargoyle and Lectrote.
Aha – For some reason my interpreter was set to Glulxe. This issue seems to occur when Lectrote is set to Glulxe or Git. It does NOT occur when set to Quixe.
I’m afraid I still can’t reproduce this. I am testing Lectrote 1.5.3 on Windows 11, using Glulxe as the interpreter. The grid window row count is always rounded down, so that a whole number of rows appear (and the last one has an asterisk).
I have tried to match your display preferences by setting the margins to zero and the color theme to “sepia”.
The difference between Windows 10 and 11 really shouldn’t be relevant here, although I guess anything is possible with Windows.
I managed to reproduce it by setting the “zoom level” (in preferences) to “Zoom Out 1”. (That is, reduce the text size.)
In my test window (which will be a different size from anybody else’s test window, but I want to record the numbers) I have glkote’s measure_window() returning
(There’s other values but these are the relevant ones.)
In Quixe, the grid-row computation goes like this: the window height is 783-2*16 = 751. Then the number of grid rows is (751-11)/17.60003 = 42.045, rounded down to 42. (This happens in glkapi.js line 3226.)
In Glulxe/Git, the analogous computation returns 43. I don’t have a way to console-log the computation, but I know that measure_window() is returning exactly the same values.
My guess is that the gridcharheight value is getting cast to an integer 17, which then screws up the grid row computation. Dannii will have to say exactly where that happens.
If the “zoom level” is zero, then gridcharheight is an integer already so the bug does not occur.
