ac@utgpu.UUCP (04/24/87)
I too have been unable to get select to work. My original work was done with DISPLAY and ECHO commands but after Mike Knudsen's posting I tried BASIC09. Not only did my temporary window not go away but my system crashed. It crashed so well that if the disk drive motors happened to still be turning at the time of the crash, then they stayed turning. I assume this means the clock 'tick' routine is no longer getting control. Eventually I got a very stripped down version of the program to work after merging it with Runb. If you haven't already guessed, I only have 128k. (Mike, do you have 512k?). I think I have seen this sort of hard death before on level II when it runs short of memory. So. I went back to playing with DISPLAY and ECHO. After booting OS9 I tried echoing messages to W1 and then W2 (using their default attributes). Then I added various display commands each of which displayed 1b 21 to a chosen window. In all cases I tried, only the first display command actually had an effect. For example: echo hi >/w1; display 1b 21 >/w1; echo ho >/w2; display 1b 21 >/w2 Results : puts hi in window 1 selects window 1's screen for display and puts cursor in window 1 puts ho in window 2 BUT doesn't move cursor to window 2 I'm not sure if this a feature of the SELECT function, but it would seem to severely limit the usability of the windows! -- Name: Mark Acfield (University of Toronto Computing Services) Path: ihnp4!utgpu!ac Alias: ac@utoronto.bitnet
knudsen@ihwpt.ATT.COM (mike knudsen) (04/27/87)
In article <1987Apr24.154112.1399@gpu.utcs.toronto.edu>, ac@gpu.utcs.toronto.edu (Mark Acfield) writes: > I too have been unable to get select to work. My original work was done > with DISPLAY and ECHO commands but after Mike Knudsen's posting I tried > BASIC09. Not only did my temporary window not go away but my system crashed. Glad I'm not alone. Some friends in the local OS9 club have found the bug too, so I guess it's for real. I was planning to use just DISPLAY too, to check Basic09, but you saved me the work. > It crashed so well that if the disk drive motors happened to still be turning > at the time of the crash, then they stayed turning. I assume this means the > clock 'tick' routine is no longer getting control. Eventually I got a very > stripped down version of the program to work after merging it with Runb. > If you haven't already guessed, I only have 128k. (Mike, do you have 512k?). > I think I have seen this sort of hard death before on level II when it runs > short of memory. Yes I have 512K. I don't think memory is the culprit here. My crashes were less severe than yours -- I could still CLEAR to another window I'd set up earlier. (I HAVE had crashes like yours from other causes -- requiring power down before rebooting.) > So. I went back to playing with DISPLAY and ECHO. After booting OS9 I > tried echoing messages to W1 and then W2 (using their default attributes). > Then I added various display commands each of which displayed 1b 21 to > a chosen window. In all cases I tried, only the first display command > actually had an effect. For example: [deleted] > puts ho in window 2 > BUT doesn't move cursor to window 2 > I'm not sure if this a feature of the SELECT function, but it would seem > to severely limit the usability of the windows! At least you were able to get it to print to the original window. I think a lot of applications don't really need to switch the interactive cursor to other windows, just make them appear on the screen after writing/drawing to them. There doesn't seem to be any way to separate these two functions, tho. Yes, this "feature" really limits the usefulness of windows, since it essentially restricts us to manual selection. Can just see some fancy spreadsheet popping up a dialog box (overlay window) that says: "Flog the CLEAR key till you see the new Pie Chart". I think Microware has too much class (even after hanging around Ft Worth) to call this BUG a "feature." -- 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] "
ac@utgpu.UUCP (05/01/87)
More on the window problem. I repeated several earlier experiments, this time making sure I had first got rid of /term. As I mentioned in an earlier posting the BASIC09 programming example for select works OK. There still are problems when I try to make a similar experiment work with the display command. The main symptom is that the entire screen clears to a grey shade and then you have to hit clear to get back to the original window. After that, clear seems to work correctly. In particular the grey screen doesn't reappear as a result of hitting clear again. In the "display" version of the experiment I had to use several display commands strung together with semicolons to allow output to be redirected to different windows. Each display is therefore a different task and the various paths to windows are being closed and reopened in this case. This may account for the difference in result from BASIC09. -- Name: Mark Acfield (University of Toronto Computing Services) Path: ihnp4!utgpu!ac Alias: ac@utoronto.bitnet