Moderators.Jon.Pugh;Dwayne.Virnau;Lance.Nakata@SUMEX-AIM.STANFORD.EDU (06/06/88)
INFO-MAC Digest Sunday, 5 Jun 1988 Volume 6 : Issue 58 Today's Topics: StuffIt-140B announcement (BackGround Task bug-fix) Macs on planes windows for hypercard Re: FINDER: there should be a way up! re: smalltalk & word perfect VCR for Mac II? audio for CD ROM machines... InvisiHDMainBo3b Packet radio Wheels for the Mind - AppleLink Address? problem with INITs ---------------------------------------------------------------------- Date: Mon, 30 May 88 14:24:50 CDT From: werner@rascal.ics.utexas.edu (Werner Uhrig) Subject: StuffIt-140B announcement (BackGround Task bug-fix) From: raylau@dasys1.UUCP (Raymond Lau) Newsgroups: comp.sys.mac Subject: StuffIt 1.40A Problems Keywords: System 6.0 and/or MultiFinder Message-ID: <4685@dasys1.UUCP> Date: 29 May 88 14:11:07 GMT Organization: The Big Electric Cat There is a known problem if the "Allow Background Tasks" feature under the Options menu is checked. All should work if it's unchecked. Alternately, 1.40B, just a bug fix for that, is available as of this writing, from GEnie,CIS,MacNET..... By this afternoon, that'll include Delphi also. If you do not need the feature, 1.40A works fine if it's unchecked. The problem occurs under System 5.0 (the collective numbering for 4.2) and MultiFinder OR the new System 6.0 (collective numbering) I neglected releasing a fix until yesterday (5/28) because I only had a beta of System 6.0. I wanted to make sure it worked with the "real" 6.0 first. Sorry for the inconvenience. I'd suggest that you mail me a copy of any problems you may have...I do not keep up with news. Feel free to spread the information. -Ray -------- raylau@dasys1.UUCP ------------------------------ Date: Tue, 31 May 88 16:59 EDT From: Henry Lieberman <Henry@AI.AI.MIT.EDU> Subject: Macs on planes Reply-to: Henry@AI.AI.MIT.EDU I have taken my Mac on airplanes many times, but it is still somewhat risky to do so. I've never been prevented from flying with it, but I have had a few close calls. The problem is that although the Mac [old Mac with small keyboard] will fit under many airline seats, it will NOT fit under ALL such seats. Example: on a DC-9, it will fit under the aisle and center seats but not under the window seat. Try to find out what kind of aircraft it is before choosing your seat assignment. [Perhaps some one will get inspired to make a survey of different aircraft and report the results here]. On a DC-10 or 747, it will [usually] fit into the overhead bin, but this is risky, especially on crowded flights since others may have filled the bin with baggage by the time you get to it, leaving no room for the Mac. Flight attendants often object to leaving it in the closet up front. On commuter hops with small planes, there may be no space for it at all. The worst problems happen when several people on the plane have brought Macs or other computers or bulky baggage, so I would not recommend carrying one if you can avoid it when you're flying to something like MacWorld. If you ask the airlines, they will always say no, since the regulations say they don't have to accept luggage as big as the Mac, and they want to discourage you from carrying it. ------------------------------ Subject: windows for hypercard Date: Wed, 01 Jun 88 08:34:37 -0800 From: duggie@jessica.Stanford.EDU Jeff Skastis <skaistis@SLEEPY.CC.UTEXAS.EDU> writes: >I am trying to write an XCMD that will place a window (or dialog) on top >of the regular Hypercard window. I would like this XCMD to plop the >window onto the screen and return some sort of ID to Hypercard. The >window needs to remain above the Hypercard window at all times, but still >let action take place in Hypercard (just like the message box and tool >palettes). The window is removed by another XCMD that takes the ID passed >from the first. I've written a window that does this. It supports multiple, resizable windows with color pictures, text, or dialogs in them. However, it is rather large and complex, consisting of a large XCMD, a special WDEF, and a system patch. Depending on your needs you might get by with less. The problems I had were how to keep Hypercard active, how to draw stuff in the window including scroll bars and the grow box), how to detect events in the window and inform hypercard, how to move, show, zoom windows etc, and how to handle hiding windows when multifinder switched out hypercard. I decided to use a patch to GetNextEvent. In another version, I tried using jGNEFilter, but multifinder ignores it (bug or feature?) and when I asked Apple they suggested I stick with the patch. This took care of most of my problems. Most of the actual code, however, resides in the WDEF, not the patch-- the patch just dispatches to it. It turns out that Hypercard stops listening to the mouse when it gets a deactivate event. My hack for solving this problem was to not pass deactivate events to windows that were not my windows or DA windows. Hypercard then remains active all the time. Occasionally there are problems because highlighting in hypercard's message box remains even though my window is getting keypress events, but basically this works. To draw stuff in the window, I pass update events to the XCMD and let the window determine what to draw. The window draws structure-like items (scroll bars and grow box) and then whatever other data it has. To detect events, I take keypresses and mouse clicks and pass them to the WDEF as well. My WDEF has an 'event queue' for each window, plus a mask to determine whether to queue the event. The events are not the same as toolbox events, but a bit more high-level-- window moved, window resized, close or zoom box pressed, button pressed, etc. If an event is queued, I post the relevant data to the window's queue (timestamp, mouse location, button id or whatever) then return a function key event via the GNE patch. Each window is assigned a function key to use for reporting events, this makes it easier for a script to determine which window has the event. My scripts keep a list of window addresses (returned by the XCMD when it creates the window) and the function key is the index of the address in the list. So to complete the reporting of the event, the script, on receipt of a function key event, gets the window address from the list and makes calls the XCMD asking for the next event for that window. The XCMD returns a string representing the 'event record.' Since this is mostly all compiled code, this process is quite fast. Hypercard is by far the slowest link. I use this to put up confirmation dialogs (using hypercard's answer command) when the user clicks in the close box of a window. The XCMD and WDEF work together to handle commanding the windows from hypertalk scripts. The XCMD parses a command string to determine the data to pass to the WDEF, supplying defaults where appropriate (when changing text parameters, for instance, any that are not provided default to their existing values). It builds a record and then calls the WDEF proc passing a pointer to this record rather than an event, and passing a special command code (not one of the existing WDEF codes). The WDEF then takes over, resizing or scrolling the window, adding or removing gadgets like the zoom and close boxes, tracking the grow box, or whatever. Hiding windows is handled by the patch, since Hypercard 1.2 has no script handlers for multifinder application switched events. This is currently a hack-- I get the head of the window list from a low memory global, build an array of windows, then walk through it hiding all of those that are of my type. Since hidewindow changes the window list, I can't just walk through the list. Restoring windows is done in the opposite way. Unfortunately, I don't record the previous window array, and hypercard shows and hides its own palette windows, so I have no way to restore the exact order of windows that existed before hypercard got switched out. Anyway, this should be enough info. Stanford owns my window XCMD or I'd post it. Perhaps they will release it eventually. By then, probably Hypercard will support multiple windows. That will obviate most uses of my XCMD except for the color picture, scrolling, and zooming support. Creating windows for Hypercard was remarkably easy, considering how much mucking around under Hypercard I had to do. Doug Felt AIR, Courseware Authoring Tools Project Stanford University duggie@jessica.stanford.edu ------------------------------ Date: Wed, 1 Jun 88 10:31 PDT From: Francois F. Ingrand <Felix@AI.SRI.COM> Subject: Re: FINDER: there should be a way up! >Date: Tue, 24 May 88 12:18:24 EDT >From: Pedro de Rezende <rezende@corwin.ccs.northeastern.edu> >Suppose you are at the Finder and you have open the window of a folder F >way down in the tree directory, while having closed all windows for the >ancestors of that folder. How do you open a sibling of F? Well, you have to >open F's parent which can only be achieved if you start from the root (the >disk). In other words, the Finder doesn't let you climb back up the >hierarchy of directories (like the SFGet dialog of HFS Systems do). >Apple may have thought of that since Finder 6.0a, which I once saw with a >pre-release version of Juggler (before Multifinder was out), had the >following feature. If you double-clicked on the title bar of an open >window, the window corresponding to the parent folder would pop open, >regardless of whether any of the ancestors folders was open. This feature >vanished with the released Finder 6.0. NO, It is still here, even in Finder 6.1 (System Software Vresion 6.0), but it is not the default. If you want to set it up, call ResEdit (mine is 1.2d1), open the Finder, open the LAYO resource, open the only one which is in it (id 0 I guess). Look for the: "Title Click" (or something like that) field, and set it to yes (or 1). And it works very fine. This one of these hidden goodies features of the Finder. In fact, I think that the guy ou wrote Layout (nice piece of code), a shareware which enable you to set up some parameters of the LAYO resource (mainly, spacial layout) should upgrape his program to take into account the new slots which appears lately. Hope it helps, Felix ------------------------------ Date: Wed, 1 Jun 88 14:18:54 PDT From: digiorgi@VLSI.JPL.NASA.GOV Subject: re: smalltalk & word perfect Re: Info-Mac Digest vol 6, #54 Smalltalk for the Mac II Apple Smalltalk v0.4 is compatible with the Mac II and runs reasonably well, given its pre-release status. It is an implementation of Smalltalk-80 based upon the Xerox License 1 system, ie. it has no multiple inheritance and a slightly different class structure from the License 2 system as described in the Addison-Wesley books. It also runs on Mac Plus and SE machines although somewhat slowly. It is not MultiFinder compatible and really wants more than 1Meg to function; I run it in 2Meg with good results. Available from APDA for $75 currently. Apple Smalltalk v1.0 is rumored to be available somewhere around the end of the year and is allegedly a License 1 system with a MacApp based interface paradigm, diverging from the MVC interface of Xerox/ParcPlace Systems (see next note) Smalltalk. I know little more of this at this time. ParcPlace Systems of 2400 Geng Road, Palo Alto, CA is a spinoff from the Smalltalk founding group of Xerox PARC. They have excellent Smalltalk-80 implementations available for Sun, Apollo, Hewlett/Packard and Macintosh Plus, SE, and II computers at the present time. Their Smalltalk-80 systems are full implementations of the Xerox License 2 systems described in the Addison-Wesley books, with many enhancements. The Mac based systems are designed for a minimum 2.5Meg RAM configuration and include basic, extended and developer systems with full support for the Mac II color capabilities. They are MultiFinder compatible, assuming sufficient RAM. Unaccelerated Mac Plus and SE systems are quite useable and the Mac II system is benchmarked at 108 Dorado (the Smalltalk Dorado reference is 100). These systems are code compatible across hardware platforms to a very high degree. Re: Info-Mac Digest vol 6, #54 Word Perfect for Mac I have a copy of the Word Perfect betaware and the final release 1.0 product. It works, has many features, and I think it is the worst word processor for the Mac I have ever seen. Never before, for a Mac word processor, has it been ABSOLUTELY REQUIRED to have the manual open on the desk to get beyond the simplest operations of the program. This seems a terrible kludge and a level of complexity simply uncalled for. Even Word is elegant and simple by comparison. I heartily suggest choosing some other word processer if such exists to meet your requirements. Godfrey DiGiorgi digiorgi@jpl-vlsi.arpa Wed, Jun 1, 1988 The above remarks are my own. ------------------------------ Date: Tue, 31 May 88 07:35:38 PDT From: KARNEY%PPC.MFENET@NMFECC.ARPA Subject: VCR for Mac II? Does anyone know of an editing video cassette recorder which works off a Mac II? Here's what I want to do: (1) Generate individual frames on a color Mac II. The time to generate a single frame may be long (> 1 minute). (2) Record each frame on a VHS VCR. This involves backing up the tape sufficiently, starting the tape movement, recording the Mac II frame on one or more successive frames on the tape, stopping the tape. The recording should be triggered by the Mac II, so it can be left unattended. (3) Take the completed tape and play it back at full speed on a standard TV set (and optionally play it back the Mac II). The key point is that the time taken to generate the frames is long. So a VCR which merely converts the Mac II video signal into NTSC format and records that is no good. Charles Karney Plasma Physics Laboratory Phone: +1 609 243 2607 Princeton University MFEnet: Karney@PPC.MFEnet PO Box 451 ARPAnet: Karney%PPC.MFEnet@NMFECC.ARPA Princeton, NJ 08543-0451 Bitnet: Karney%PPC.MFEnet@ANLVMS.Bitnet CC: INFO-MAC@SUMEX-AIM.STANFORD.EDU KARNEY ------------------------------ Date: Wed, 01 Jun 88 15:48:18 EDT From: Jeremy Bornstein <JEREMY%BROWNVM.BITNET@Forsythe.Stanford.EDU> Subject: audio for CD ROM machines... Would someone please give me a pointer to the DA which allows one to make the CD-ROM drives play audio CDs? It would be much appreciated. Please reply to jjb@gorgo.harvard.edu. Thanks! -jeremy bornstein ------------------------------ Date: Wed, 01 Jun 88 14:12:30 EDT From: Atul Butte <ST602397%BROWNVM.BITNET@Forsythe.Stanford.EDU> Subject: InvisiHDMainBo3b I have a file called InvisiHDMainBo3b on my hard drive. It is in the root directory. It takes up 325460 bytes in the data fork, and has no resource fork. It is flagged as Invisible. I recognized the Bo3b as the name of someone from Apple (see your TechNotes). What is this file? Do I need it? It's taking up a lot of room. _______________________________________________________________________ Atul Butte Brown University /-------\ /---------\ . ! OK ! ! CANCEL ! . \-------/ \---------/ ST602397%BROWNVM.BITNET@MITVMA.MIT.EDU ------------------------------ Date: Tue, 31 May 88 11:39 N From: <RUUD%HTIKUB5.BITNET@Forsythe.Stanford.EDU> Subject: Packet radio I am posting this messages for a friend. Hi, in the free world of ham radio a lot of people are interested in packet radio. I want to know more about packet-radio-software for the Mac. Does anyone know something about Brincomm, 2404 Stockton Pl Marietta CA. Any information is highly appreciated. Peter van der Hoog Please mail to Ruud@HTIKUB5.bitnet ------------------------------ Date: Thu, 02 Jun 88 10:49:16 EDT From: Atul Butte <ST602397%BROWNVM.BITNET@Forsythe.Stanford.EDU> Subject: Wheels for the Mind - AppleLink Address? I understand that it is possible to send mail and files from BITNET onto AppleLink. In that case, what is the AppleLink address of the people who manage contributions for Wheels for the Mind? I think it would be great if contributors could just EMail their submissions (articles, screen dumps) to the right people instead of using USnail mail. In addition, this would be a great non-commercial use of the AppleLink-BITNET connection. Thanks in advance. _______________________________________________________________________ Atul Butte Brown University /-------\ /---------\ . ! OK ! ! CANCEL ! . \-------/ \---------/ ST602397%BROWNVM.BITNET@MITVMA.MIT.EDU ------------------------------ Date: Thu, 2-JUN-1988 13:47 +0200 From: "KARL::WIM" <U0036%DGOGWDG5.BITNET@cunyvm.cuny.edu> Subject: problem with INITs I have a problem with my INITs. On startup some of them are executed twice. This happened after I changed the ID of one INIT 31 to 30 and then pasted in another with ID 31 into the system file. Question is: then why are the other INITs (in the system folder) executed twice. I don't feel like playing around with the debugger. Which guru helps me out ?? (I'm running System 4.2, if that helps) W.Elhorst U0036@DGOGWDG5.Bitnet ------------------------------ End of INFO-MAC Digest **********************