ADVERTISEMENT

Mousehole Report

By Rusty Hodge & Larry Nedry, Mousehole BBS

From: thecloud (Ken Mcleod, La Habra, CA)

Subject: ScrollRect()

I’d like to be able to use ScrollRect to cause one bitmap to scroll down *into* a window, as the contents of that window are simultaneously scrolling down out of the visRgn. Trouble is, the update region gets filled with the port’s bkPat (white) by ScrollRect, and this results in a “flash of white” before I can get the area redrawn. Can anyone point out a strategy for accomplishing this “smoothly”? I’m currently doing something like this:

for (i=1; i <= appropriate_multiple_of_inc; i++) {
ScrollRect(&theRect, 0, inc, myRgnHandle);
ScrollRect(&anotherRect, 0, inc, myRgnHandle);   
Draw_Stuff_In_anotherRect()  }

but I’m sure I just need someone to kick me in the right direction!

From: rdclark (Richard Clark, Tustin, CA)

Subject: A kick in the right direction

Look at the articles by Scott Boyd (“The MacHax Group”) in the past 2 years of MacTutor -- they show how to do some pretty weird stuff with off-screen bitmaps and the like, including a trick to get rid of the “flash of white” when moving/updating a window.

From: lsr (Larry Rosenstein, Cupertino, CA)

Subject: Re: ScrollRect()

The best thing to do is to create an offscreen bitmap and use CopyBits to draw the bitmap on the screen in its proper position. If I understand your application correctly, you want to smoothly change from one image to the other. In that case, you would need to have the combined image offscreen, and use a series of CopyBits calls to draw the appropriate rectangle on the screen. (You would start out by copying the entire first image, then most of the first and part of the second, etc.)

CopyBits works the fastest when Quickdraw doesn’t have to shift every scan line. If you can control the position of the window on the screen, then you should make sure that its global screen position is a multiple of 16 (or 32 on a Mac II).

There probably is a way to prevent ScrollRect from erasing things, but the resulting effect wouldn’t be acceptable either. You would notice the delay between the ScrollRect and the redraw.

From: thecloud (Ken Mcleod, La Habra, CA)

Subject: Re: ScrollRect()

It always comes down to CopyBits in the end! Thanks...

From: robert (Rob Anthony, Chicago, IL)

Subject: MacIntalk

Check out APDA (Apple Programmers and Developers Assoc., in Renton, WA). They had -- in their ‘Curiosity Shoppe’ section -- the MacinTalk Development Package v. 1.31. It has docs and tools for using MacinTalk (they say). I don’t have it, so I can’t give any personal experience, but the APDA folks should be able to answer your questions. Need to be an APDA member to order; about $20 a year for that, but well worth it for the Mac programmer.

From: rhyman (Richard A. Hyman, Morrison, CO)

Subject: Desktop File

Prior to release 5 of the system software, the invisible Desktop file contained a resource called FOBJ that contained info on the open directories, view-by type information, and so on. The Finder used this info when starting up after quitting an application or during the boot-up. The FOBJ resource no longer exists with the newer system releases except for 400k MFS volumes. Does anyone know how this information is stored under system releases 5 & 6??

From: lsr (Larry Rosenstein, Cupertino, CA)

Subject: Re: Dialog Hook Procedure Problem

The problem is that you are using a local procedure, and the ROM is expecting a procedure at the top level. This is true of all the ROM routines that expect a pointer to a procedure. (In Pascal, nested procedures expect to find an extra parameter on the stack, which is a pointer to the enclosing stack frame.)

From: mwatts (Michael Watts, Santa Clara, CA)

Subject: limit on scroll bar value

Hi. I am new to the mousehole and have spent an informative session catching up. There is one question which I need help on if someone would be so kind.

In the app which I am writing, I have to deal with data which contains more than 32k points. I want to scroll through this data using a scroll bar, however the max value is an integer (opps). Even if I write my own control, in IM V I-333 the upper value for the CNTL resource is 2 bytes (not enough). I have kludged a fix by breaking the stream into 32k point sections, however this adds another control to my window and complexity to the program.

Does anyone know how to get around this problem, and if so how?

From: thotpolc (Bill Evans, Irvine, CA)

Subject: Re: limit on scroll bar value

“Doctor, it hurts when I do this.”

“Don’t do that....”

Your kludge to break the stream into 32k point sections is a good start. I don’t think the designers of the Mac interface and toolbox really anticipated someone scrolling more precisely than this. Notice, however, that the scroll bar is between two arrows, each of which points away from it. You could use these to scroll more precisely. To get the flavor of this, use any word processing program to create a document with more than 64k lines. (Probably short lines will make the whole thing a little easier.) Then scroll back and forth, using all parts of the scroll bar: the thumb (which is that funny white box you can slide back and forth with your... well, with your thumb), the gray parts of the bar itself, and the arrows at each end. In a well-tempered word processor, a single click in one of these arrows should move you up or down by one line; holding down the mouse in one of these arrows should, after a short while, start scanning through the document in small increments. Go thou and do likewise.-- the Thought Police

From: rdclark (Richard Clark, Tustin, CA)

Subject: Re: limit on scroll bar value

There are a couple of ways to take care of your problem:

1) Redesign the software so that a single click on the down arrow moves you down by n points instead of 1 point (where n could be 1/4 screen or something.) Some how, I don’t think that’ll be satisfactory for you. 2) Write a custom control definition that uses something larger than an integer (an unsigned integer, maybe?), then avoid using calls like “SetCtlValue” and “GetCtlValue”. Fortunately, there’s a set of options available to you in writing a custom control definition that allow you to get away without Set/GetCtlValue. The first problem involves dragging the “thumb” portion of the scroll bar. If you look at IM I-331 and I-332, you’ll see that you can write a “drag”, “position”, and “thumb” routine that override the control manager (I suspect that the control manager uses the get/set control value calls.) These could read your “extended” position information and adjust the control accordingly. That leaves a different problem -- what happens if the user clicks in one of the arrows?? You’ll need to pass a message to your control to adjust itself by 1. The only reasonable way I can think of doing this is to make one of your control messages do double duty (you don’t want to pick a new message number since Apple might decide to use that message someday, and that could hurt.) How about calling the control definition with a second (third, fourth...) “initCntl” message and a special value in the “param” parameter?? Your definition could recognize the special value (or the fact that you’re already initialized) and adjust itself accordingly.

On second thought, why not just live with a scroll bar position which is an approximation of the real position?? After all, we won’t be seeing 33K pixel by 33K pixel screens in the near future, so all your extra effort won’t mean much on the display.

From: mwatts (Michael Watts, Santa Clara, CA)

Subject: Re: limit on scroll bar value

That is a good suggestion. I was fixating on using the scroll bar value as my numerical indicator on where I was in the data set. Your suggestion implies I have a position variable which is incremented by the scroll step parameter and then position the thumb relative to the size of the data set.--a very “thoughtful” piece of advice.

ps- I still consider this a kludge solution. there should be a way to have the value of the scroll bar be a long integer.

From: rdclark (Richard Clark, Tustin, CA)

Subject: Re: limit on scroll bar value

Actually, I like the thought police’s answer MUCH better. (But I never could resist a good challenge!)

From: thotpolc (Bill Evans, Irvine, CA)

Subject: Re: limit on scroll bar value

rdclark (Richard Clark, Tustin, CA) writes:

On third thought, if you want exactly what you want without kludges, why not throw away the whole idea of part numbers and messages doing double duty and custom control definitions, and just do the whole durn thang using normal QuickDraw calls? I did this once with buttons which I wanted to have a special shape, and it was fun! If I ever use scroll bars, I’m going to want the thumb to be not square, but long enough to show what portion of the document is on the screen. That way, for example, if almost all of the document is on the screen and you’re at the beginning of the document, you’ll see a thumb which occupies almost all of the scroll bar, with a small gray area at the bottom. And if you click in that small area, you’ll see a large thumb move a small distance (while the data on the screen is doing exactly the same thing), not a small thumb jump grotesquely from the top to the bottom of the scroll bar.

And if I ever get around to having this fun, you can bet I’ll do it all without a formally defined control definition, thank you very much.

Does any of this give you the feeling that my favorite language is assembly? -- the Thought Police

From: rdclark (Richard Clark, Tustin, CA)

Subject: Re: limit on scroll bar value

Actually, it’s giving me a feeling that you’re a GEM fanatic! (duck incoming tomatos)

From: dhands (David Hands, Salem, OR)

Subject: MPW Print Interfaces

In the interface files of MPW Pascal there are two files, PrintTraps.p and MacPrint.p, that contain roughly the same calls. What’s the difference and when should one be used over the other?

From: think (Think Technologies, Bedford, MA)

Subject: Re: MPW Print Interfaces

PrintTraps.p is the trap-based interface to the Print Manager; the traps are implemented in the Mac SE and Mac II ROMs, and in System 4.1 or later on all machines.

MacPrint.p is the glue-based interface, and will work on all Macs, on all versions of the System software.

Rich Siegel Staff Software Engineer THINK Technologies Division Symantec Corp. Mousehole: think Usenet: singer@endor.uucp

Any opinions stated here do not necessarily represent the views or policies of the Symantec Corporation.

From: think (Think Technologies, Bedford, MA)

Subject: Lightspeed Pascal 2.0 Ships!

The following is excerpted from the press release announcing the shipment of THINK’s Lightspeed Pascal and Just Enough Pascal. the official announcement was made yesterday (Monday, November 14) at COMDEX, in Las Vegas.

“Symantec Corporation today announced THINK’s Lightspeed Pascal(tm) version 2.0 and Just Enough Pascal(tm) are shipping this week.

For a limited time, beginning this week, Symantec will bundle a copy of Just Enough Pascal in specially marked boxes of THINK’s Lightspeed Pascal. the suggested list price of the bundle is $149, and the promotion will continue until January 31, 1989.

Just Enough Pascal is the first tutorial of its kind, taking an inter- active approach to teaching the fundamentals of Pascal programming on the Macintosh. Users learn by building a real Macintosh game application in THINK’s Lightspeed Pascal, with all instructions and explanations provided on-line. As the user builds the program through various stages, he sees the results of each code change graphically illustrated on the screen.

New version 2.0 of THINK’s Lightspeed Pascal now generates the fastest, most compact code of any Pascal compiler available for the Macintosh. It provides options to generate code for the 68020 and for the 68881 math coprocessor, and features full access to all of the Macintosh ROM routines.

New and enhanced features of version 2.0 include: a fast, multipass optimizing compiler which produces compact, commercial-quality code; Object Pascal support; increased editor flexibility for virtually unlimited program size; and enhanced source-level debugger; and language extensions for improved compatibility with Apple’s Macintosh Programmer’s Workshop (MPW) Pascal.

Special introductory list pricing for THINK’s Lightspeed Pascal version 2.0 is $125. The price will increase to $149, effective February 1, 1989. Just Enough Pascal’s suggested list price is $75.

Registered owners may upgrade to THINK’s Lightspeed Pascal version 2.0 for $52.50 ($49 plus $3.50 shipping and handling; CA residents must add 7% sales tax, for a total of $55.93}. To upgrade, users must send a letter, including payment (US checks only) and registration number to:

Symantec Corporation Customer Service Department 10201 Torre Avenue Cupertino, CA 95014 ATTN: THINK’s Lightspeed Pascal 2.0 Upgrade

Purchasers of version 1.11 or earlier who bought the product after July 1, 1988 are entitled to a free upgrade. A dated proof of purchase must accompany the upgrade request. Further upgrade information is available from Symantec’s Customer Service Department at (408) 252-3570.

Symantec will also extend the special $175 introductory pricing of THINK’s Lightspeed C version 3.0 through January 31, 1989. Effective February 1, 1989 the price will increase to $249.” Rich Siegel Staff Software Engineer THINK Technologies Division Symantec Corp. Mousehole: think Usenet: singer@endor.uucp . [Any opinions stated here do not necessarily represent the views or policies of the Symantec Corporation. Pricing is still being determined by Symantec at Press time. -Ed]