2623 - bugfix: editing sandboxes

If you restore 2 sandboxes, the first render was setting
response-starting-row-on-screen on both, without ever rendering a
response. If the lower sandbox contained a print and rendered the screen
instead of the response, the original response-starting-row-on-screen
was never reset. If the process of running the sandboxes caused the
lower sandbox's title bar to move below the now-stale
response-starting-row-on-screen[1], editing the lower sandbox no longer
works.

[1] (Either because the upper sandbox prints to screen as well (causing
the first F4 to move the lower sandbox down by several lines), or
because a fresh sandbox is created with several lines before the first
F4 is hit.)

Current solution: never set response-starting-row-on-screen during
reload (or otherwise when there's no response).

This is hard to test right now because 'restore' is not a tested
interface, and I can't come up with another situation where the
response-starting-row-on-screen goes stale. So I'm now trying to keep
all changes to response-starting-row-on-screen close together. Another
idea is to add a check that the click row lies below the
response-starting row *and* above the start of the next sandbox. (But
what if there's no next sandbox?)

(This bug is really a regression, introduced last Sep in 2163.)

1 files changed, 1 insertions, 0 deletions

diff --git a/sandbox/010-warnings.mu b/sandbox/010-warnings.mu
index a20e306d..8ceb88bb 100644
--- a/sandbox/010-warnings.mu
+++ b/sandbox/010-warnings.mu
@@ -118,6 +118,7 @@ after <render-sandbox-trace-done> [
   {
     sandbox-warnings:address:shared:array:character <- get *sandbox, warnings:offset
     break-unless sandbox-warnings
+    response-starting-row:address:number <- get-address *sandbox, response-starting-row-on-screen:offset
     *response-starting-row <- copy 0  # no response
     {
       break-unless env