Path: news.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!math.ohio-state.edu!darwin.sura.net!ukma!mthvax.cs.miami.edu!not-for-mail From: bsherman@mthvax.cs.miami.edu (Bob Sherman) Newsgroups: comp.sys.apple2 Subject: Pointless <-> 6.0.1 problem Date: 12 Jul 1993 18:55:24 -0400 Organization: Not much! Lines: 23 Message-ID: <21sq4sINN6pm@mthvax.cs.miami.edu> NNTP-Posting-Host: mthvax.cs.miami.edu I spoke today with Tony Gentile at Westcode customer support. He tells me of a new workaround for the problem that shows up when using Pointless with GSOS 6.0.1. He said an easy way to solve the problem is to just replace the font manager tool (tool 025) in 6.0.1 with the one from 6.0. That will solve the problem and eliminate the need to save a bit mapped copy of every truetype font that you use. He is going to send me a copy of some tech info on this workaround that they have posted on Genie and AOL, and when I get it, I will repost it here. He did mention that Apple does not officially endorse this workaround, as they do not like you to mix old tools with newer operating systems, but Westcode feels this will not cause a problem with any existing software you might be using. The changes to tool 025 he says were very minor, but enough to cause the problem that has been reported.. Westcode does not at this time monitor the Internet Apple feeds, but at my suggestion hopes to gain access to them shortly. They did not realize how active the feeds here are. (Morgan Davis, if you are reading, your Pro-Line site is what I suggested to them).. -- bsherman@mthvax.cs.miami.edu | | MCI MAIL:BSHERMAN an764@cleveland.freenet.edu | | Newsgroups: comp.sys.apple2 Path: news.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!math.ohio-state.edu!cs.utexas.edu!utnut!wave.scar!90taobri From: 90taobri@wave.scar.utoronto.ca (TAO BRIAN T) Subject: My list of System 6.01 bugs Message-ID: Reply-To: 90taobri@wave.scar.utoronto.ca (Brian Tao) Organization: MuGS Research and Development Facility X-Newsreader: MuGS 3.0d29 [Jul 18 93] Date: Wed, 21 Jul 1993 22:16:15 GMT Lines: 68 Here's what I have so far. Everyone knows about the Pointless + 6.01 bug, so I won't list it again. 1. Keyboard navigation in Finder still active when info window in front. This is confusing (since L and I keys also used for Locked and Inactive checkboxes). 2. Closing window always selects enclosing icon, even when other icons are selected. This is contrary to the readme file. I've complained to Jim Murphy about this but he tells me they decided to make it more consistent with the Mac. I personally find this philosophy distasteful, but what do I know about GUI design? :-P Temporary solution: use the Piece 'O String FExt. 3. I've found a bug which is caused by (2), so maybe this will convince Jim & Dave to put it back the way it should be. ;-) Insert a few floppies and open a window on each of them. Select all the floppy icons and drag them to the trash. Guess what? After the first window closes, Finder forgets to put away the other floppy icons! Why? Because it undoes your icon selection and highlights the floppy whose window was just closed. Ta da. I don't like the Finder overriding my icon selections like this. I can use the Mac's Finder for this type of aggravation. Please put it back to the way it was before (or to the way it is described in the System 6.01 readme file). 4. Finder still counts each icon one by one when preparing for a copy. This slows things down unnecessarily. Can't it count all the files in one big shot (the way it counts files hidden inside a directory)? 5. Bill Tudor's "CDev Alias" NDA no longer works under System 6.0.1. 6. When highlighting text using Shift+arrow in LineEdit box, text does not scroll if cursor extends past edges of box (i.e., I can't see how far I'm extending my selection). 7. Startup sound not purged after playing. I thought this was going to be fixed for 6.01. 8. Need some way to bypass auto-select feature in the Finder, or speed up the routine. It slows things down too much in a medium-sized directory, not to mention a few with 100+ files. This is with a Zip 8/16 and I got a taste of what it was like on a stock 2.8-MHz GS last night. Not a pretty sight. 9. Icon in Info window not updated when file changes (but filetype description does). 10. Scroll bar not updated in window when icons added/removed. You have to resize the window to update the scroll bar. I was running YankIt in the background (in GNO, of course ;-)) and the file icons kept magically popping up in the Finder window, but I couldn't scroll around until I manually resized it. 11. File icon does not change in Finder when "Inactive" checkbox changed. I have two sets of generic NDA/CDA/CDev/etc. icons. The inactive version has a red X through it, and it is matched to auxtype $8000. BTW, this only works for files whose native auxtype is $0000 to begin with. I took an NDA with a X'ed out icon, unchecked the "Inactive" box and the icon didn't change. One suggestion: how about giving us back our horizontal scroll bars in list views? An old, old version of the Finder (1.0? 1.1?) had this feature, but it was taken out for some reason. Since you're trying to make the GS Finder act like the Mac Finder.... :-P -- Brian Tao:: taob@io.org (Internex Online, 416-363-3783, 10 lines, v.32bis) ::::::::::: 90taobri@wave.scar.utoronto.ca (University of Toronto, 9T4) Newsgroups: comp.sys.apple2 Path: news.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!math.ohio-state.edu!usc!elroy.jpl.nasa.gov!decwrl!decwrl!apple!mumbo.apple.com!gallant.apple.com!kip-68.apple.com!dlyons From: David A Lyons Subject: Re: My list of System 6.01 bugs Sender: news@gallant.apple.com Message-ID: <1993Jul22.214258.686@gallant.apple.com> X-Useragent: Nuntius v1.1.1d27 Date: Thu, 22 Jul 1993 21:42:58 GMT X-Xxdate: Thu, 22 Jul 93 22:32:11 GMT X-Xxmessage-Id: References: Organization: Apple Computer, Inc. Lines: 52 In article TAO BRIAN T, 90taobri@wave.scar.utoronto.ca writes: > ... > 2. Closing window always selects enclosing icon, even when other icons > are selected. This is contrary to the readme file. I've complained to > Jim Murphy about this but he tells me they decided to make it more > consistent with the Mac. I personally find this philosophy distasteful, > but what do I know about GUI design? :-P Temporary solution: use the > Piece 'O String FExt. I'm mostly responsible for ramming that change through--with keyboard navigation the inconsistency became really obvious. You could sometimes-but-not-always do a Command-W followed by a Command-Y to eject the front window's disk, for example (when the disk icon was not already selected). The bug is we forgot to change the Shortcuts file. The paragraph should read: "For your convenience, the Finder automatically selects a disk!s icon when you insert the disk. Also, when you close a window the Finder automatically selects the disk or folder icon into which the window closed." [That is, delete the text from the end that said "..., if no other icons would otherwise be selected (the Finder assumes that if you selected icons in another window or on the desktop, it should leave them selected)".] > 3. I've found a bug which is caused by (2), so maybe this will convince > Jim & Dave to put it back the way it should be. ;-) Insert a few > floppies and open a window on each of them. Select all the floppy icons > and drag them to the trash. Guess what? After the first window closes, > Finder forgets to put away the other floppy icons! Why? Because it > undoes your icon selection and highlights the floppy whose window was > just closed. Ta da. I don't like the Finder overriding my icon > selections like this. [...] That's an interesting bug. I think my fix would be to notice that the disk icon being closed into was -already- selected, and not deselect everything in the case. I didn't respond to most of your points--they are legitimate points, but in most cases the answer is simply "Hey, it works as well as or better than in 6.0, and resources were limited." Dave Lyons, dlyons@apple.com Mr Tangent My opinions are my own, not Apple's. Newsgroups: comp.sys.apple2 Path: news.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!math.ohio-state.edu!wupost!waikato!comp.vuw.ac.nz!actrix.gen.nz!dempson From: dempson@swell.actrix.gen.nz (David Empson) Subject: System 6.0.1 Organization: Actrix Information Exchange Date: Wed, 4 Aug 1993 13:24:06 GMT Message-ID: <1993Aug4.132406.7116@actrix.gen.nz> Sender: dempson@actrix.gen.nz (David Empson) Lines: 92 Resource Central to the rescue, again: I received 6.0.1 yesterday, and have been doing some experimentation. Overall, it looks very good. Many thanks to Dave, Jim and the rest of the IIgs team at Apple for their continuing efforts. It is much appreciated! The MS-DOS FST has already been very useful - I can extract ARC files in GS ShrinkIt directly from an MS-DOS disk in my SuperDrive. The RAM5 driver is also a major improvement - my RAM disk is now faster than my SyQuest. I had one puzzling problem when I installed 6.0.1. I am intending to get AppleTalk running on my computer shortly, so I decided to install all of the AppleTalk software, but disable it (by marking a few files Inactive). Upon the initial boot, I got _two_ warnings about AppleTalk not being enabled (one early in the boot sequence, prior to INITs being loaded, and the other much later). I knew one of them was from the AppleShare FST (as with System 6.0), so I disabled that. I thought the other one was coming from the AppleTalk main driver (ATalk), but disabling it didn't get rid of the message. It turned out that I had to disable SCC.Manager to get rid of the second warning. I don't recall having to do this with System 6.0. I have encountered one major problem, with the A2.RAMCARD driver and my PC Transporter. Before installing 6.0.1, I had already booted 6.0 (and the PC Transporter's drivers had been loaded into the card). From a clean 6.0.1 installation, the A2.Ramcard driver seemed to be working fine - my PC Transporter RAM disk was running along at a good pace. However, after I used the PC Transporter's PCINSTALL program to patch the PRODOS file, the A2.Ramcard driver started misbehaving. Whenever I got into Finder, it would bring up the dialog: "There are two volumes called :RAMAEPC online" (Eject/Initialize). If I ejected the disk, it vanished from the desktop, but was still available from other programs (ORCA/Shell, for example). If I chose to initialize it, I got a second error dialog, which was something like: "Getting errors reading /RAMAEPC" (Eject/Initialize). Every attempt to initialize the disk produced the same dialog, _unless_ I gave the disk the same name as an existing volume (e.g. /RAM5). I then got a "duplicate volume" dialog, and after renaming the disk back to /RAMAEPC, it seemed to be working fine. However, on the following boot, the same problem happened again. Until I can sort out the problem, I've disabled the A2.RAMCARD driver, and I'm relying on the generated GS/OS driver (which works fine, if slowly). I had similar problems with the System 6.0 version of A2.RAMCARD - it always asked to reformat /RAMAEPC on the first boot. The 6.0.1 problem is much more serious, though. I managed to analyse the problem with 6.0's driver: it seemed that the very first DRead call to /RAMAEPC after a boot was reading 256 zero bytes in the first half of the block. Since the first read was the directory block, this was causing GS/OS to think the disk wasn't formatted. I was able to get around the problem by doing a single-block read to /RAMAEPC before Finder was loaded. I have yet to try this trick with the 6.0.1 driver to see if it has the same problem. I'm running version 2.0 of the PC Transporter software. Is anyone else out there using a PC Transporter successfully with the A2.RAMCARD driver (either 6.0 or 6.0.1)? If so, which version of the PCT software do you have? -- David Empson dempson@swell.actrix.gen.nz Snail mail: P.O. Box 27-103, Wellington, New Zealand Path: news.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!math.ohio-state.edu!sdd.hp.com!decwrl!decwrl!usenet.coe.montana.edu!news.uoregon.edu!cie.uoregon.edu!nparker From: nparker@cie.uoregon.edu (Neil Parker) Newsgroups: comp.sys.apple2.programmer Subject: More about Teach crashing in ChooseFont dialog Date: 14 Sep 1993 08:46:18 GMT Organization: The Universal Society for the Prevention of Reality Lines: 60 Message-ID: <2740cq$kkr@pith.uoregon.edu> NNTP-Posting-Host: cie.uoregon.edu Summary: I did some disassembly. Did I find the bug? For those who tuned in late, here's the bug: Boot System 6.0.1 and double-click on Teach. Type a few characters in the new document window, and then select "Choose Font" from the Fonts menu. Click on the "Plain" checkbox. Your GS should now be lost in never-never-land. (This is not the infamous Font Manager vs. Pointless bug...I don't own Pointless, and the FixFontMgr INIT doesn't cure it, and neither does shift-booting. Teach seems to be the only program affected.) Are any of the folks at Apple with access to the Font Manager and/or Teach source code reading this? I tried disassembling portions of ChooseFont, and I'm not sure whether or not I found the cause of the bug, but I did find some suspicious code in exactly the right place to be causing it. Basically, the ChooseFont call sets up some lists to contain the fonts and sizes, and then calls DoModalWindow to put up the dialog box, and MWGetCtlPart to find what (if anything) the user selected, and then comes the following code: pha ;Space for result pha pei <$BC ;$BA apparently contains the handle of the pei <$BA ; selected control _GetCtlRefCon pla plx bne SkipDisp ;Skip dispatch table if HiWrd(RefCon)!=0 cmp #$A bcs SkipDisp ;Skip dispatch table if LoWrd(RefCon) > 9 asl A tax lda >DispatchTable,X ;Get subroutine address SkipDisp dec A pha ;Push address-1 onto stack rts ;Go to it via RTS trick The part that worries me is the part that branches around the fetching of the dispatch address if the RefCon of the selected control is greater than 9. Is is possible that Teach is somehow mangling the RefCon of the "Plain" checkbox so that the branch is occurring when it shouldn't, or isn't occurring when it should? In either case, it would cause the RTS to branch to God-knows-where instead of to the correct handler whenever somebody clicks on the affected control. In any case, I'm somewhat puzzled by the presence of the code to bypass the indexing into the dispatch table. If the intent was to provide a way for something to override the standard dispatch table by poking an arbitrary address into the control's RefCon, then it fails miserably--you'd need to push three bytes and RTL instead of two bytes and RTS. By the way, I noticed that the ChooseFont dialog's controls, and their RefCons, are obtained by calling GetROMResource. Where does GetROMResource get its resources? *:System:System.Setup:Sys.Resources? - Neil Parker -- Neil Parker No cute ASCII art...no cute quote...no cute nparker@cie.uoregon.edu disclaimer...no deposit, no return... parker@corona.uoregon.edu (This space intentionally left blank: )