Letters

More on Self-Destructing LaserWriters

Rod Paine

Just finished reading your “LaserWriters Self-destruct” letter. While you are correct in terms of the effect the damage fuser roller has on the printed output, I don’t believe that the “rubber paper guides” are the cause of the problem, at all. I have two LaserWriters and have experienced the problem on one of them, requiring the replacement of the fuser assembly. The second one is maintained based on correcting what I found on the first and what appears to be a proper solution to the problem.

The problem is that toner builds up on the back side of the “Fuser Separation Claws”, cooks and becomes hardened to a point where it begins to scratch away the fuser roller surface coating. It appears to only build up on the two center claws, the two outside claws don’t seem suseptable to this build up of tonner. [Mine is on the outside claw! -Ed] I have since checked the two Canon PC-25 copiers that we have, which have almost identicle fuser assemblies and they exhibit the same problem. So does my own personal Canon PC-10 copier.

I discussed this with the two Apple dealers that we purchased these LaserWriters from and made two phone calls to Apple at Cupertino. The dealers know nothing and Apple has never returned my calls. I called Simplified Copiers, the firm that sold us the canon PC-25 copiers, they also know nothing about this problem. I have looked at the fuser assembly in detail (I replaced the damaged one, a very simple task) and am confident this is the cause of the scratches. As the LaserWriter owner manual makes no mention of cleaning this area I think this is a serious problem.

If you have any contacts at Apple who will address this problem, please include my name. In fact, if you want to look at the fuser assembly I replaced, I’ll send it to you. In the meantime, keep the back side of the fuser separation claws clean and clean the fuser roller everyday, BEFORE you turn it on, including taking a look at the cleaning felt strip, that slides into the “green felt cover”, look which is known as the “fuser upper cover”. I’m glad to see you bring this up, I was getting nowhere fast!

Color Mac Not Finished

Lawrence D’Oliveiro

The Mac II arrived at work about three months ago, and the draft copy of Inside Macintosh Vol.V not long after. After long hours wrestling with documentation that is inadequate, incomplete, and often down right wrong, I managed to convert some grey-scale pictures we have on the Vax into colour QuickDraw format. In the process, I to learn how to create my own GDevice, in order to construct off-screen pix-maps. Tech note #120 doesn’t really provide the answer, as I wanted to create PICTs with 256 colours in them, and my video card can only handle 16 colours/grey scales at the moment. I expect lots of other people would have gone through this and already discovered what I know, but if not, one or two of my programs might be worth publishing.

I eagerly typed in Steven Sheets’ colour game of life in the september issue, and had some fun with that. There was a bug in DoColorClick (which lets you change the set of colours the program uses), which caused it to ignore any changes you specified -- to fix this, just the following line:

 mycolors[i] := ColorIt;

Before the call to MakeRGBPat, after the begin. Apart from that (and the missing resource definitions), it’s a pretty demonstration, which I’ve shown lots of people. Thanks, Steven.

Apple colour monitors are a little bit thinner on the ground than snow in December over here, but I managed to borrow an NEC MultiSync to try out for a couple of weeks. Picture quality isn’t 100%-- the picture narrower in the darker parts-- though I expect the newly-announced MultiSync Plus should work better.

I may be wrong, but it doesn’t look like all the pieces of colour supply for the Mac II are in place yet. Some documentation mentions a control panel module for changing the colour table, but I can find no such module anywhere. I wrote a quick-and-dirty utility for doing a similar thing (using the SetEntries colour Manager call), but my changes kept getting undone as soon as I exited the program. Eventually I dumped out the current colour table to a “clut” resource, pasted this into the System file, and put its resourse ID into the “scrn” resource, in the marked “CLUT rsrcID”. Now my program worked, even though I wasn’t updating the clut resorce on disk! The colours reverted to those in the resource when I rebooted-- I tested this by modifying the resource, it did have the expected effect. The only trouble was when I changed screen mode bit to 2 or 1 bit per pixel (the clut I created had 16 entries), and rebooted-- the screen colours went all funny! Verdict: something is missing that Apple should be supplying. [The Pallette Manager? -Ed]

The other thing I found is that MakeRGBPat, which approximates a colour you specify by “ dithering” (making up a pattern using available coloursin the colour table in the right proportions), isn’t very accurate. Quite frequently, I would ask it to approximate a colour which exactly matched an entry in the colour table, and it would mix in a bit of black instead of giving me a pure colour. Maybe in system 4.2...

I hope this information is of use to others. After the silence of the Mac Plus, and the enhanced Fat Mac I was I was using before that, tha Mac II sounds like your in a jet plane. But then it performs like one!

Apple Looking for a few Good Men

David E. Smith

At Apple’s request, we have sent a letter to each of the 385 past contributors of MacTutor to advise them of employment opportunities at Apple. If you have made a contribution or requested an author’s kit from MacTutor in the last three years, you should have received this letter. If you did not, then you are no longer in MacTutor’s editorial computer for one reason or another and you may wish to contact me for a new author’s kit. Apple has a number of technical management positions open and are looking for experienced Macintosh programmers such as those who write for Mactutor! For more information, contact Dan Cochran at Apple.

Absoft Fortran Update

In last month’s MacTutor, we implied some problems with Absoft’s new version of Fortran for the Macintosh II. We are happy to report that version 2.3 of MacFortran/020 is now shipping, having received our copy on 25 Sept 1987. Mr. Wood Lotz, President of Absoft also responded to the disgruntled customer and he is perfectly satisfied now. The manual has been re-written and now includes new information on the added features. The linker has been improved with a script builder utility that automates the link process. The linker is now a batch facility rather than a poorly designed interactive facility as it was in the past. In this respect it is more similar to the MDS and Consulair linker. The compiler includes options for selectively generating 68020 and 68881 instructions. It also continues to support the generation of assembly source code, a feature we think is invaluable and lament that other compiler makers have not supported this. Absoft’s Fortran remains the only Macintosh compiler product that uses 32-bit offsets in it’s addressing and does not use the segment manager. Thus there are no 32K code, segment or array limitations in MacFortran/020 as there are with virtually all MPW compilers. Now that the product is sold and supported directly by Absoft, we expect customer satisfaction to improve considerably over the previous Microsoft implementation. Absoft can be contacted at (313) 853-0050.

New MPW Fortran

Language Systems Corp. of Herndon, VA has announced their development of a new MPW Fortran product. The product is scheduled to go into beta test in December. An information booth on the product will be available at the January Mac Expo in San Francisco. The product will feature 68020 and 68881 code options and will be linkable with all MPW compiler products. Variable types will include 68881 extended and complex precision as well as a new type called STRING for dealing with Mac Pascal type strings with a length byte. Assembly source code output will also be available. Since this Fortran operates under MPW and uses the MPW Linker, it will be impacted by the segment manager limitations of other MPW products. However, arrays and common variables will not be restricted to 32K, according to a company spokesman. For more information, contact Language Systems at (703) 478-0181.

Power Supply Woes Revealed

Herbert M. Rosenthal

Chuck Rusch (June ’87, p13) hit it right on the head with his article on soldering imperfections in the early Macs!!! He has my undying gratitude for his comments and specifics which led me directly to the several intermittent, offending unsoldered connection(s) that had me rapping on the side of the Mac more often than one should, to restore the video. I had installed an internal fan and varistor (both Radio Shack) a year ago, and am convinced that the fan kept my board from “smoldering.”

One simply cannot see these cold joints without a magnifying glass, regardless of his hardware experience. Further, simply re-heating joints will not make a good connection; it is necessary to apply a wee bit of fresh, rosin solder to the joint as it is heated; the flux will cause the solder to flow properly. Finally, if you’ve braved the storm this far, clean up the work with a toothbrush dipped in alcohol; scrub till all the flux is cleaned up, dry the brush and scrub some more.

MacApp Aids Complexity

Charles Turner

For some time now I have been incorporating some of the structure and flow concepts of MacApp, mostly gleaned from Kurt Schmucker’s book Object- Oriented programming for the Macintosh, into my LightSpeed Pascal program in order to retain a reasonable amount of generality, modularity and maintainabilty as it grows increasingly complex. I looked to MacApp for inspiration since it was developed with objectives similar, at least in part, to my own and with a lot more talent and inspiration than I could put to that problem.

Anyhow, it seems that much of the structure and flow in MacApp is different from the traditional generic program and may be generally useful. Also, fortunately, much of it can be implemented without the need for object programming.

Since most of the programs you have published derive from the short sample in Inside Macintosh Vol . I and Chernicoff’s Macintosh reaveled , a sample of somthing a little different might be interesting to readers who are battling the problems of increasing complexity. There are lots of ideas in MacApp just waiting for the light of presentation, assuming that Apple doesn’t mind.

Of course talk is cheap and writing is dear, but if you think the subject has merit and would send an author’s kit, perhaps I could postpone the 127th improvement to my program and get something together. And then maybe, just maybe, a moment of immortality on the cover of Mactutor. [Write away, author’s kit is ‘in the mail’. -Ed]

Camera Option for Cmd-Shift-3

Neil Ticktin

Response to August 1987 - Macintosh II Hierarchical Menus - Documenting programs (page 50). There is a desk accessory called “Camera” by Keith A. Esau. I believe that it is public domain or shareware. It takes a “snapshot” of the screen after a user specified amount of time. It also allows you to make the cursor invisible. The resulting snapshot is in Macpaint format or can be sent to the ImageWriter. I believe that you can get the desk Accessory from CompuServe or other information networks. [The Camera DA does not work on a Mac II in color mode. In fact, none of the “paint” type programs work on a Mac II set up for 256 colors. This is one of the great needs for the Macintosh; new paint programs that can work with color monitors. There is still no way to capture the screen image of a color display. -Ed]

Resonse to August 1987 - Mousehole Report - “more woes... from: mysteray”. ComputerWare, of Palo Alto (CA 800-323-1133 or US 800-235-1155), is begging to sell kits to replace the Macitosh SE fan with a much quieter fan. I believe the kits sell for arround $40. I don’t know if it will also solve the interference problems that I also have on my SE. I have not yet bought the fan , but I intend to.

“No-Fluff Stores”

David Kauffman

In response to your APDAlog ad, I would like to commend what I consider to be Vancouver’s best “no-fluff” computer store, Silicon-ections Books Ltd.. They stock an excellent selection of user-oriented and technical-oriented books on microcomputers, networking, publishing as well as sections on UNIX, Artificial Intelligence and Computer Science. Thier staff are helpful without being pushy and know thier stock very well. Thier knowledge of Mac technical issues is a little lacking to be the kind of gurus you might be looking for, but I recommend thier store as the best candidate in the Vancouver area. [Thank you. We encourage all Macintosh technical users to send in their “No-Fluff” favorite so we can compile a list for the “rest of us“ technical types to patronize. -Ed]

Major Havoc vs. Mr. Clean

Jean-Michel Decombe

It’s always been a pleasure to recieve the latest issue of Mac Tutor. Your articles are useful but I don’t understand why VIP is great in your opinion. I don’t know of any good programmer who would use it. OK, you have two types of programmers: Major Havoc & Mr. Clean. Major Havoc, of course, doesn’t use VIP; he simply transfers garbage from his brain to the RAM via the keyboard; he doesn’t care much about fancy graphics. And Mr. Clean can’t see an overview of his project with VIP; he can’t put remarks where he’d like to; what he sees on a full screen is about four lines of code; and scrolling isn’t fun. Now take a non-programmer. He won’t learn programming faster with VIP. OK, you have direct access to the parameters of the ROM routines, but it doesn’t help you a lot. You’ll have to learn how these routines work, when they should be used, the side effects, and so on. I think Zippy is right: If I use VIP, do I have to give my project manager ten per cent?? So, I’d like to know who should use VIP. Thank you for your answer, if any.

I send you a very very small but very very handy trick if you frequently use any debugger. Aldo Reset made it for me:

1) Jump to ResEdit, to open your System file, then open the FKEY resources.

2) Choose New from the file menu; a window appears with blinking caret. Type the following hex string in:

487A 0006 ABFF 4E75 1842 6162 7920 4569 6E73 2773 2044 6562 7567 6765 
72

4) Close the window and choose Get Info from the File menu. Change the type to BED (Baby Einstein’s Debugger), the ID to a number between 5 and 9, or 0, Which isn’t the ID of any of other FKEYs, then set the Purgeable attribute.

5) Close and save everything, then return to shell.

Now, you can access the debugger installed by typing Command-Shift-ID, where ID is the ID of the BED FKEY. In the hex string, the underlined part is a Pascal string that you can change whatever you want. Just remember the first byte is the length. You can of course use a smaller or longer string, up to 255 bytes. Have fun!

[I think VIP is fun! VIP procedures replace ten to 20 ROM routines with a single VIP command, which greatly reduces the code needed to generate a Mac program. Printing text from a window is a single procedure call in VIP. Compared with a compiled language like Pascal, the same effect would take several pages of complex print manager code. All five translators for LS C, MPW C, MPW Pascal, Turbo Pascal and LS Pascal are now completed. Mainstay translated and compiled a single VIP program in all five languages and found out the MPW translations were twice as fast as the Turbo and LS products. More on this work will be available next month. VIP may be the ideal prototyping language with the added benefit that the design can be turned directly into code. I invite others to comment on the suitability of using VIP for software development. -Ed]

ZBASIC Comments & Shift Mod Patch

Steve Millman

Your September issue lived up to its usual fine standards, and as always, taught me a lot of things I wanted to know. I do have two comments/questions, however.

1. David Kelly’s Basic School article shows how to write a full event loop in ZBASIC, which is useful. Howoever, the expressed purpose was to allow the program to check for a specific type of event, such as a disk insertion, that ZBASIC doesn’t handle. The full event loop seems like a lot of work (and seriously reduces the benifits of using BASIC in the first place). Why doesn’t something like the following work in place of the usual ZBASIC empty loop:

“loop”:
 IF FN EventAvail(p,   disk  event  mask)  GOSUB  
 “handleit”:   GOTO  loop
 MENU ON :  MOUSE ON:  DIALOG ON
 REM
 MENU OFF:  MOUSE OFF: DIALOG OFF
 GOTO “loop”
“handleit”:
 ans=FN  GetNextEvent(p,  disk  event  mask)
 whatever action program is supposed to take
RETURN

The only problem I can see with this type of workaround is if the disk insertion event is posted at a time no other events are on the queue and between the line turning ZBASIC event trapping on and off (so that ZBASIC reads the event and discards it). I can’t imagine this will happen very often.

2. The ShiftMod note, which was incredibly useful to me (because I didn’t know how to do an epilogue patch) fails to note that the program will not affect the behavior of DA’s--If you type a key with the caps lock and shift down when the fwindow is a DA, the result will will be a capital letter. No, I didn’t really try ShiftMod, but I used a modified version to imitate Loftus Becker’s ToggleKeys on the new system. (ToggleKeys, which is probably not much use to programmers is virtually a necessity for people like me who do a lot of normal style typing. It makes the shifted comma and period keys print as comma and period rather than “<“ and “>”. It modifies the key mapping. When Apple changed the KeyTrans vectors in System 4.x, it made ToggleKeys-- and its big brother Keymap-- unusable.) Since I don’t understand the KeyTrans stuff at all (despite an otherwise excellent article in a prior issue), changing the characters returned by GetNextEvent seemed best. It works fine as long as you are typing in an application. In a DA, though, the INIT is ignored.

Why? After a lot of searching through Inside Macintosh, I discovered when a DA window is frontmost, the DA KeyDown events are sent directly to the DA by GetNextEvent-- by the time ShiftMod gets to look at the returned event, the DA has already used it.

One, not quite perfect solution that I tried, is to use a patch GetNextEvent with a prologue instead of the top of the event queue and if that event is a Keydown or Autokey event, it modifies the character code.

This works fine for keydown events and most of the time for auto events. However an occasional autokey event doesn’t seem to get the message. I don’t know why and I’d love an explanation for it if you have one. (I guess that sometimes GetNextEvent is pulling the autokey from further down in the stack. I could understand this if GetNextEvent where being called with a mask EveryEvent, but the problem doesn’t seem to be limited to only one application.)

Animated BitMaps

My bad typing led me into a closer look at the code in the Animated BitMaps article. In function InitDrag, Scott violates one of the most clearly stated prohibitions inside the Macintosh-- he directly modifies the visRgn of a grafPort with:

 RectRgn(thePort^.visRgn,thePort^.clipRgn^^.rgnBBox);

“The visRgn... is reserved for use by Macintosh system software, and should be treated as read-only. The default visRgn is set to the portRect.”-- Quickdraw C.4 [I cannot find this reference, although the IM I-149 does state that the programmer “normally should not modify the visRgn” -Ed]

He had plenty of incentive to do so-- DrawPicture respects the visRgn and will refuse to draw any bits in your off screen bitMap that are outside of the visRgn.

I finally found a way to stay legal but also to draw successfully: just before using DrawPicture in the NewDraggable procedure, set the origin of the off screen bit map to the top left corner of the picture’s pictureframe. Then, set the port bits. SetOrigin has the nice property of adjusting the visRgn, legally, as a side benifit.

Replace this code in NewDraggable:

OpenRgn;
Hlock(handle(thePicture));
DrawPicture(thePicture,thePicture^^,picFrame);
HUnlock(Hndle(thePicture));
CloseRgn(thePictureRgn);

with this:

MoveHHi(Handle(thePicture));
Hlock(Handle(thePicture));
with thePicture^^.picFrame do
 SetOrigin(left,top);
SetPortBits(pictureBits);
OpenRgn;
DrawPicture(thePicture,thePicture^^.picFrame);
HUnlock(Handle(thePicture));
CloseRgn(thePictureRgn);

Naturally, you should remove the offending RectRgn statement that illegally modified visRgn in InitDrag. Effective animation is delightful; thanks Scott.

Raving on Mac

Gary Odom

Time to blow the horn on some software.

Just got QUED/M, the new macro editor from Paragon concepts. It is excellent, and ca onsiderable improvement on the earlier QUED. The macro facility is real sweet, if not yet complete (Paragon is working on adding more pizzaz, though it’s more than powerful enough for what I need). There is a powerful built-in grep (for those who don’t grok UNIX, that’s a multiple file search utility). My only beef is the use of “non-standard” menu-keys (‘w’ for save instead of ‘s’, for example). It took me about thirty minutes of hacking in ResEdit to adjust the menu keys to taste. for all the time we devlopers spend munching ASCII, we deserve a quality editor. This is it.

I keep on seeing advertisements for Inside Mac reference tools. Well, Bernard Gallet has written a wonderful DA with Inside Mac Vols.1-4 contained therein. Extremely convenient, and for it’s $10 suggested shareware price, it’s a prize.

Tooting my own horn for a paragraph: why spend $25 for a Mandelbrot set generator when you can get one heckofa Mandelbrot zoom lens for free (hmm, the cost of a download)?! MandelZoom 3.0 is available on GEnie (Education library, author G. Odom). It is REAL slow because it is inSANE, but that’s only if you want to zoom down to 1 to the 10-billionth. The program allows one to save data plots for later retrieval, and you can use good ole “point n’ click” to select new pictures. If you’re into Mbrot, you should definetly check this one out.

I leave with a kick to the tush to you C code puppies out there (and I’m referring to some I’ve seen in MacTutor). The braces should line up, guys and gals, as should everything else.

struck goodbrace { struct badstyle  {
 short eye; short on_looks;
 short read;long on_nonsence; 
 };     };

Isn’t it obvious the way to go? With the braces vertically aligned, It’s so easy to see where the code clauses begin and end, and verify proper code structure. Hey, get with the program!

New MPW Book

Charlie Nash

I would like to recommend to your readers an exceptional book find-- “MPW and Assembly Language Progamming” by Scott Kronick, published by Howard Sams Co. What makes the book stand out is that it actually teaches Macintosh assembly language. This contrasts with the myriad of “Inside Macintosh” clones that shoot for comprehensivness at the expense of explanation.

Also, it’s the first book I’ve seen that explains the basics of MPW. This is useful since the MPW docs run over 1200 pages. [Yes, this is a good introductory book on MPW and assembly; read it first before moving on to Dan Weston’s two volume set. It is written in the unique Kronick style; lots of interesting diversions along the way. Scott, Charly wants a free disk for this plub! -Ed]

Mac vs PC for Fortran

Keith Bierman

The author (September MacCad article) compares the Mac to the rest of the (computer) world as a FORTRAN development system. As much as I love my Mac, it is not an outstanding FORTRAN development system. Paul explains that the Mac cuts development time due to its quick compile and execute cycles. I did not have the author’s code handy, so I used some of my own. The source code consisted of 4794 chars (Mac version, a few less for the PC, as there is no need to have a dummy common to reserve enough stack space). Test: Running a Mac+ with a LoDown 20 Mb disk, going from QUED/M to MS/FORTRAN, selecting the file for compilation and linking and creating a list file (to make the comparison fair, see below), then executing the code (which produces about 18,533 characters of output). In the other corner, my trusty PC-Tech X-16B (8 mhz-80186/8087 w/1Mb memory running PC-DOS 3.2; Seagate 225 HD (very slow for this machine-there is an onboard SCSI Capable of operation at 4+Mb/s; unfortunately I am not utilizing it, so IO is at slow PC-bus speed) compilation from within the editor, and for contrast recompiling from the OS, followed by a LINK (including many more libraries than needed) and executed.

MAC PC

compile for syntax 34s 14s

compile and execute 69s 43s

The difference between my figures and the authors is not due to hardware differences, but due to the choice of PC compiler. The Lahey compiler generates code (if one turns off all the safeties) that runs within a few % of Microsoft’s “highly optimizing” compiler, but compiles 10x faster. (Lahey simply generates good code, and makes no claim about optimizing - probably because Tom understands what a real optimizing compiler is expected to do, from his days creating Mainframe FORTRAN’S).

In order to debug a Mac Program, I nearly always need the “listing” option, since the error messages are otherwise lost (or must be hand copied!). This is not necessary on the PC. LCS fully supports NAMELIST-a creature comfort that makes porting code to /from minicomputers and mainframes much easier.

Also hidden is the fact that the LCS compiler produces much better error messages. Mismatched argument lists (checked at compile and at run time), flags unused variables, and much, much more. The LCS compiler is good enough that it merited the purchase of the PC clone! The time saved made the purchase well worthwhile. The debugger is not as visual as the Mac, but offers more features, and there is a code profiler which times by line or by subroutine, with 1msec resolution. There is an 80386 version, which takes advantage of the larger memory space, and some of the new op-codes.

The PC has many programmer oriented editors (none as good as QUED/M, but more than a dozen products which try hard). I use a rather simple one, which permits multiple windows, fair performance, and allows me to load and execute the compiler in its own window, Until Juggler is in my possession (and actually works!) the Mac is worse off! MacFORTRAN certainly does not have an integrated editor, and I have yet to meet any users of DCM’s FORTRAN.

Paul makes many good points, and the Mac is a good choice (especially with a 68020/68881 combo). Aside from the compiler itself, the Mac is a much better environment: QUED/M is vastly superior to any other editor, the ability to port FORTRAN output (including plots) to reports and documentation, etc. makes it a very attractive choice. But, until MacFORTRAN’s develop, the PC (O.K. a PC clone with a 20 mhz 80386/87 from A.I Architects) yields a more powerful, easier to develop number crunching code environment than the Mac. If one wants a consistent user interface and such... well the Mac wins hands down. Technical reports, and other documentation tasks, again the Mac.

One last point: the Levco Mac is in the same price range as a minimal SUN, which has a much better FORTRAN environment, much higher network performance, and (at present) more connectivity (nearly any UNIX system). Of course a minimal SUN doesn’t include a hard disk, but if you have 3 or more people, the SUN fileserver yields better performance than a local Mac disk! [Apple has not paid enough attention to the need of making engineering quality compilers available on the Macintosh. However, we think this is changing fast and that the continued improvement of Absoft Fortran/020 and the arrival of MPW Fortran products will encourage more powerful number crunching compilers on the Mac II. -Ed]

Mac Programmer Friendly?

Dr. Robert A. Stine

What is important is the development environment that comes with the compiler, and here again there are two sides of the coin. I spend a lot more time debugging code rather than compiling and linking. If we look at C (and I think a lot of us do ), then I think that Apple fans will be hard pressed to match the Codeview debugging environment of MS-C in the DOS world. Also, a very cheap C compiler for IBM’s has a very nice debugging environment (MIX-C about $40), and the Datalight Optimizing C can do great things for slow code.

In contrast, Lightspeed C, for example suggests using Macsbug--gag, I thought hex dumps were a thing of the past. Mac software is supposed to be user-friendly, but often seems to be very programmer-unfriendly.

With that off my chest, I’ll keep searching for a good Machintosh C implementation, and I hope that you will keep coming MacTutor issues as good as those I’ve come to expect. [Macintosh is most decidely programmer un-friendly and has always been so. MacApp is Apple’s response to this complaint. While I am being moved to MPW, I have never considered that a programmer-friendly environment in the Mac tradition. To date, only LS Pascal has a friendly source level debugging capability. Comments fellow hackers? -Ed]

Larry’s Copybits Code

Fernando Salazar

I want to thank Larry Rosenstein for his letter in the August 1987 MacTutor (“BlockMove vs CopyBits”). I learned a lot from the letter - I’ll never be shy about using CopyBits again! I also wish to address some of his comments on my code.

First, on hiding the curser, the code presented in my July issue letter does a HideCursor before each BlockMove, then a ShowCursor after. The same effect could be achieved with one ShowCursor at the end; but if the drawing that occurs in between takes a couple of ticks, the cursor appears to flicker.

More important is what the OffScreenDraw procedure presented in my July letter does. I use this procedure for re-drawing a scrolling window; the procedure makes an offscreen copy of the current port’s bitmap, draws the scrolled version to it, then transfers the copy back to the screen. Even though bits outside the bitmap bounds may be copied to the temporary bitmap ( i.e. when bounds.right-bounds.left is less than rowbytes*8), they should be identical when copied back to the original bitmap, since drawing doesn’t modify bits outside a grafport’s portBits.bounds (IM v1, p155). If the bounds rectangle changes in between the first BlockMove and the second (as would happen if there was a call to PortSize or MovePortTo) then all bets are off.

It may be interresting to note that the program that uses this BlockMove method is my shareware application “CK” (available on CompuServe), and that I have had reports of it being used on a Mac SE under System 4.1/Finder 5.5 with no problems. But Mr. Rosnstein’s admonitions about code incompatabilities with new configurations are correct; CK certianly would not work on a Mac II.

The only reason I used a BlockMove scheme in the first place was that I was unsure about the CopyBits 3.5K “limit”. CopyBits is the one of the most important QuickDraw calls, yet it seems to have a lot about it not publicly understood. In another example, Robert Denny’s article “PICT Rotation with CopyBits” (Best of MacTutor Vol.I, p.210) revealed that CopyBits does not accurately scale to powers of 2. Why is that? Is there a way to predict how CopyBits will scale an image? Let me add my vote for a MacTutor article revealing the inside-story on CopyBits.

Pagemaker & Down Loaded Fonts

David E. Smith

Pagemaker 2.0 has problems placing formatted MacWrite text files which contain down loaded laser fonts. Our favorite font, a mono-spaced laser font called thin Saratoga, often causes Pagemaker to respond with a dialog box claiming "using fonts not in the system file". It also has the disastrous effect of adding unwanted characters to our source code listings! We are trying to contact both the font maker and Aldus to ask about this. I suppose it's the old problem ..."go talk to the other guys!"