From 07a6418389a6c36c0fe9cded6e585fb013ec90e1 Mon Sep 17 00:00:00 2001 From: "Kartik K. Agaram" Date: Mon, 1 Feb 2016 13:29:46 -0800 Subject: 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.) --- sandbox/005-sandbox.mu | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) (limited to 'sandbox/005-sandbox.mu') diff --git a/sandbox/005-sandbox.mu b/sandbox/005-sandbox.mu index 929716a1..690ab22c 100644 --- a/sandbox/005-sandbox.mu +++ b/sandbox/005-sandbox.mu @@ -23,7 +23,6 @@ container sandbox-data [ # constraint: will be 0 for sandboxes at positions before env.render-from starting-row-on-screen:number code-ending-row-on-screen:number # past end of code - response-starting-row-on-screen:number screen:address:shared:screen # prints in the sandbox go here next-sandbox:address:shared:sandbox-data ] @@ -289,7 +288,6 @@ recipe render-sandboxes screen:address:shared:screen, sandbox:address:shared:san code-ending-row:address:number <- get-address *sandbox, code-ending-row-on-screen:offset *code-ending-row <- copy row # render sandbox warnings, screen or response, in that order - response-starting-row:address:number <- get-address *sandbox, response-starting-row-on-screen:offset sandbox-response:address:shared:array:character <- get *sandbox, response:offset { @@ -300,13 +298,12 @@ recipe render-sandboxes screen:address:shared:screen, sandbox:address:shared:san } { break-unless empty-screen? - *response-starting-row <- copy row row, screen <- render screen, sandbox-response, left, right, 245/grey, row } +render-sandbox-end at-bottom?:boolean <- greater-or-equal row, screen-height - reply-if at-bottom?, row/same-as-ingredient:4, screen/same-as-ingredient:0 + reply-if at-bottom? # draw solid line after sandbox draw-horizontal screen, row, left, right, 9473/horizontal-double } @@ -317,8 +314,7 @@ recipe render-sandboxes screen:address:shared:screen, sandbox:address:shared:san *tmp <- copy 0 tmp:address:number <- get-address *sandbox, code-ending-row-on-screen:offset *tmp <- copy 0 - tmp:address:number <- get-address *sandbox, response-starting-row-on-screen:offset - *tmp <- copy 0 + } # draw next sandbox next-sandbox:address:shared:sandbox-data <- get *sandbox, next-sandbox:offset @@ -429,6 +425,7 @@ recipe render-screen screen:address:shared:screen, sandbox-screen:address:shared ] scenario run-updates-results [ + trace-until 100/app # trace too long assume-screen 50/width, 12/height # define a recipe (no indent for the 'add' line below so column numbers are more obvious) 1:address:shared:array:character <- new [ -- cgit 1.4.1-2-gfad0