sysop@stech.UUCP (11/13/87)
I've been using MultiFinder very heavily for a while now, and thought I'd share some problems I'd run into, as well as what I found was very good about it. First, some very odd behavior: 1. Occasionally, an application will quit unexpectedly (both MacWrite and FullPaint did this). MultiFinder sends you a message that this has happened, but doesn't close the document that you were working on. With MacWrite, it means that I have to reboot the machine to close the document so that I can work on it again (selecting Close from the Finder certainly doesn't help ...). 2. At one point, MacWrite hung during a write to disk. I lost the entire text file. Thank heavens for backup copies! 3. PrintMonitor sends a message that it couldn't print a document and asks if I want to try again. The trouble is, the document has already been printed - successfully. 4. MacPaint doesn't seem to be able to talk to PrintMonitor. Regardless of which print option you pick, nothing happens. (I haven't tried MacPaint with background printing off; I simply switched to FullPaint, which works fine.) Are these bugs? Has anyone else run into similar problems? Now, some joys: 1. I had two copies of MacWrite running, each working on a different document. I was cutting and pasting between the two without any problems. It made life exceptionally easy. (Don't tell me to get a more sophisticated word processor that supports multiple windows - I dislike MS Word intensely and need something that desktop publishing programs can read!) 2. Ready, Set, Go and at least one graphics program will fit in RAM in my 2 meg machine at one time. At last, an easy way to modify graphics when using a DTP program which can't do its own graphics!!!!!! All in all, I'm very pleased to finally have MultiFinder. It makes life a million times easier, which is what computers should be all about, eh? Jan Harrington, sysop Scholastech Telecommunications ihnp4!husc6!amcad!stech!sysop or allegra!stech!sysop ******************************************************************************** Miscellaneous profundity: "No matter where you go, there you are." Buckaroo Banzai ********************************************************************************
gardner@prls.UUCP (Robert Gardner) (11/14/87)
In article <256@stech.UUCP> sysop@stech.UUCP (Jan Harrington) writes: > 1. Occasionally, an application will quit unexpectedly (both MacWrite >and FullPaint did this). MultiFinder sends you a message that this has >happened, but doesn't close the document that you were working on. With >MacWrite, it means that I have to reboot the machine to close the document >so that I can work on it again (selecting Close from the Finder certainly >doesn't help ...). Anyone know why Apple chose this weird method of NOT closing files automatically when an application quits? This has caused me more headaches than I can imagine, especially during development if the program crashes while a file is open. There doesn't seem to be any way of explicitly closing the file without rebooting or trashing the file (with option/command/whatever held down). It looks like now there's an even more compelling reason for Apple to change this. Would it break ANY existing code? Would it be that hard? Resource files are closed automatically, so why not data files? Robert Gardner
dwb@apple.UUCP (David W. Berry) (11/15/87)
In article <7399@prls.UUCP> gardner@prls.UUCP (Robert Gardner) writes: >In article <256@stech.UUCP> sysop@stech.UUCP (Jan Harrington) writes: >> 1. Occasionally, an application will quit unexpectedly (both MacWrite >>and FullPaint did this). MultiFinder sends you a message that this has >>happened, but doesn't close the document that you were working on. With >>MacWrite, it means that I have to reboot the machine to close the document >>so that I can work on it again (selecting Close from the Finder certainly >>doesn't help ...). > >Anyone know why Apple chose this weird method of NOT closing files >automatically when an application quits? This has caused me more >headaches than I can imagine, especially during development if the >program crashes while a file is open. There doesn't seem to be >any way of explicitly closing the file without rebooting or trashing >the file (with option/command/whatever held down). Actually, there is a way. Get a copy of the Developer's Tools desk accessory, along with all the normal file copy/delete/information routines it also allows you to close an arbitrary file. I added it to the DA (long before I joined Apple) for just this reason. For those of you with a more technical bent the way DevTools closes arbitrary files is to do a GetFileInfo (which returns a refNum if the file is open) and then close the returned refNum. You do have to be careful with what files you close though :-) Dev. Tools (aka Developer's Tools) should be available on your local info-mac server. If you can't find it let me know (VIA MAIL, not a posting) and I'll send you a copy, or demand justifiing it, repost it again. BTW, version 2.2 is current and has been for quite some time. -- David W. Berry dwb@well.uucp dwb@Delphi dwb@apple.com 973-5168@408.MaBell Disclaimer: Apple doesn't even know I have an opinion and certainly wouldn't want if they did.
dudek@utai.UUCP (11/27/87)
In article <7399@prls.UUCP> gardner@prls.UUCP (Robert Gardner) writes: >In article <256@stech.UUCP> sysop@stech.UUCP (Jan Harrington) writes: >> ... >>happened, but doesn't close the document that you were working on. With >>MacWrite, it means that I have to reboot the machine to close the document >>so that I can work on it again (selecting Close from the Finder certainly >>doesn't help ...). > >There doesn't seem to be >any way of explicitly closing the file without rebooting or trashing >the file (with option/command/whatever held down). > The shareware desk accessory DESKZAP (v1.2) lets you close ANY open file anytime. That feature alone makes it well worth its price. -- Dept. of Computer Science (vision group) University of Toronto Usenet: {linus, ihnp4, allegra, decvax, floyd}!utcsri!dudek CSNET: dudek@ai.toronto.edu DELPHI: GDUDEK