Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-spam!mordor!styx!ptsfa!ihnp4!ihwpt!knudsen From: knudsen@ihwpt.ATT.COM (mike knudsen) Newsgroups: comp.sys.m6809 Subject: Re: Window Problems Message-ID: <1637@ihwpt.ATT.COM> Date: Mon, 27-Apr-87 13:39:05 EDT Article-I.D.: ihwpt.1637 Posted: Mon Apr 27 13:39:05 1987 Date-Received: Tue, 28-Apr-87 03:17:06 EDT References: <1987Apr24.154112.1399@gpu.utcs.toronto.edu> Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 49 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: " ~E(x):[is_lunch(x) && cost(x)==0] "