knudsen@ihwpt.ATT.COM (mike knudsen) (04/22/87)
I've learned a little more about the disappearing windows
bug since yesterday's posting:
1. The fundamental bug is that a process can create a
window, open a path to it, send a SELECT (1B 21) code
sequence to it and write/draw in it.
But when the process tries to get its original
(interactive shell) window back by sending the
SELECT sequence to stdout, that doesn't work.
The process is left in limbo.
PS: I've tried sending the actual bytes from BASIC09
and not trusting GFX2(). Still no workee.
2. Everything else makes legal sense (maybe).
The original window is still de-selected by its shell,
which (I guess) takes it off the CLEAR-key list.
I can still CLEAR to the temporary window as long
as I don't hit BREAK while viewing it (figure
that one out -- I think that causes its shell to
close BASIC09's paths, so the window evaporates if
not INIZ'ed. The original stays deselected.
3. You CAN recover the original window, if you know
which of the BASIC09 PROCs is the lost one.
Just KILL it from another window. Then you can
usually get the window back with the CLEAR key,
certainly if you start another Shell on it.
BTW, it's not impossible to direct output to a window
that has a shell on it. The output just doesn't go thru
until you get in that window and type something there
that stimulates some output. Then the other stuff shows up.
--
Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T)
Delphi: RAGTIMER CIS: <memory failure, too many digits>
" ~E(x):[is_lunch(x) && cost(x)==0] "