This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
Bomb Bloke's profile picture

[1.63] Use of windows leaves parent's cursor out of bounds

Started by Bomb Bloke, 20 April 2014 - 08:59 AM
Bomb Bloke #1
Posted 20 April 2014 - 10:59 AM
Best I can make out this affects 1.64pre1 as well, though I've only glanced at the code for that and not specifically tested it.

For reasons I don't understand, the window API has a tendancy to leave the cursor of parent windows outside of the visible display area. Likely due to line 39:

            parent.setCursorPos( 0, 0 )

I assume it's a mistake (should be 1,1 instead of 0,0?), but if for whatever reason it's intended, I'd appreciate knowing the logic behind it. It's a nuisance - debugging is painful when your errors are rendered off-screen!

Edit: If it is for some reason essential, it'd be nice if the shell were to at least make sure that any errors produced by a given script are rendered somewhere they can be seen.
Edited on 20 April 2014 - 09:03 AM
Bomb Bloke #2
Posted 05 February 2015 - 09:18 PM
Bumpity! Still stands in 1.66pre3.
dan200 #3
Posted 08 February 2015 - 12:42 PM
It's intended. If you do window.setCursorPosition() to somewhere outside the window, or window.setCursorBlink(false), the parent windows cursor needs to be hidden, this is achieved by moving it to 0,0
Bomb Bloke #4
Posted 08 February 2015 - 01:50 PM
Ah, to hide a blinking cursor. Makes sense.

Though, assuming errors can't otherwise be forced into view, would you consider not performing the move if the child's cursor is already set not to blink? This'd mitigate the issue somewhat - cursors move out of bounds often, whereas it's relatively seldom that blinking is enabled.
dan200 #5
Posted 10 February 2015 - 06:12 PM
I might just change printError() to move the cursor onscreen if it's not already, that seem reasonable?
Bomb Bloke #6
Posted 10 February 2015 - 09:21 PM
That'd be perfect, thanks. :)/>
Lyqyd #7
Posted 11 February 2015 - 12:49 AM
If you do decide to modify the printError function, it may also be useful to set the background color as well. Currently, if the last background color set was red, any errors printed are unreadable (red on red), at least on advanced computers. I haven't tested on the normal computers, but I'd suspect that leaving the background color white immediately before an error would cause similar issues.