Feb 89 Mousehole
Volume Number: | | 5
|
Issue Number: | | 2
|
Column Tag: | | Mousehole report
|
Mousehole Report
By Rusty Hodge & Larry Nedry, Mousehole BBS
From: thecloud (Ken Mcleod, La Habra, CA)
Subject: ScrollRect()
Id 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 ports 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? Im 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 Im 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 doesnt 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 wouldnt 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 dont have it, so I cant 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.
Dont do that....
Your kludge to break the stream into 32k point sections is a good start. I dont 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 dont think thatll 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, theres 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, youll 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?? Youll 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 dont 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 youre 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 wont be seeing 33K pixel by 33K pixel screens in the near future, so all your extra effort wont 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 polices 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, Im 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 youre at the beginning of the document, youll 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, youll 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 Ill 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, its giving me a feeling that youre 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. Whats 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 THINKs Lightspeed Pascal and Just Enough Pascal. the official announcement was made yesterday (Monday, November 14) at COMDEX, in Las Vegas.
Symantec Corporation today announced THINKs 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 THINKs 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 THINKs 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 THINKs 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 Apples Macintosh Programmers Workshop (MPW) Pascal.
Special introductory list pricing for THINKs Lightspeed Pascal version 2.0 is $125. The price will increase to $149, effective February 1, 1989. Just Enough Pascals suggested list price is $75.
Registered owners may upgrade to THINKs 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: THINKs 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 Symantecs Customer Service Department at (408) 252-3570.
Symantec will also extend the special $175 introductory pricing of THINKs 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]