Jan 89 Mousehole
Volume Number: 5
Issue Number: 1
Column Tag: Mousehole Report
Mousehole Report 
By Rusty Hodge & Larry Nedry, Mousehole BBS
From:emmayche (Mark Hartman, Fullerton, CA)
Subject: Re: scroll bars
Inside Mac says that the “standard” width is 16 pixels; however, you can get some
really strange effects at different widths.
From: asc (Alex Colwell, Redondo Beach, CA)
Subject: Using PAP Manager
Has anybody used the PAP Manager lately? I had reviewed the two “Mac Tutor”
articles : Feb 1986 “Laser Print DA for Postscript” by Mike Schuster and Sep 1986
“Postscript Driver, LightSpeed C” by Bob Denny. However, when I tried to implement
this into my application. I always get “Printer Not Found” using LaserWriter 5.0,
System & Finder 6.0.1. I suspect the old LaserWriter driver and the new LaserWriter
PAP Manager has changed where the articles are currently out-of-date. Does anybody
has any ideas. Thanks.
From: dsa (Dave Stine, Saugus, CA)
Subject: Re: Using PAP Manager
If you can’t figure out what the problem is, I could upload a newer version of the PAP
Driver interface. The LaserWriter has changed somewhat since Bob’s article in
MacTutor, but we have a current copy here.
BTW, you should make sure that you have selected a LaserWriter by the full name,
including any trailing spaces. The old ‘Namer’ application has a habit of appending
trailing spaces to LaserWriter names which are odd-length when unpadded. (Silly, but
that’s what they do...)
From: rustyt (Rusty Tucker, Irvine, CA)
Subject: BitMap to Region
A while ago I thought that I saw something posted about code that will convert an Icon
Bitmap into a region. Does any body know where I could find this, or have any
examples or ideas on how to do this? Any help at all will be appreciated!!
From: emmayche (Mark Hartman, Fullerton, CA)
Subject: Re: BitMap to Region call
There exists a BitMapRgn() call from DTS. It’s a (believe it or not) separately
licensable product. We have a copy; as far as I can tell, I can only distribute it with
Photon Paint.
What it does is to convert a BitMap (no PixMaps here) to a Region. FAST. What used to
take 2 minutes now takes virtually no time. Great stuff. Give a call or drop some
e-mail if you need any more info.
From: asc (Alex Colwell, Redondo Beach, CA)
Subject: RE: Using PAP Manager
Could you possibly upload the newer version of the PAP Driver interface? Yes, I
believe, I am using the correct LaserWriter name by extracting the printer name from
the ‘PAPA’ resource with the resource ID # 0xE000. Then I pass the printer name to
the “PAPOpen” routine without any modifications.
I wrote a little text editor using Capp’s LSC PE edit routines. With this I want to send
the Postscript code from my text editor straight to the LaserWriter. So any
information you have concerning the PAP Manager would be greatly appreciated.
From: dirck (Dirck Blaskey, Highland, CA)
Subject: LSC 3.0 stdio lib
LSC 2.0 -> 3.0 library file stdfile_pos.c, function fseek():
around line 90, the code that looks like this:
pb.ioMisc = (char *) offset;
if (err = who->last_error = PBSetEOF(&pb, false))
errno = err;
return(err);
should look like this:
pb.ioMisc = (char *) offset;
if (err = who->last_error = PBSetEOF(&pb, false))
{
errno = err;
return(err);
}
this bug has the following symptoms:
if a call to fseek() causes the file to be extended, the file position will not be changed.
From: bobe (Bob Estes, Somerville, MA)
Subject: Re: LSC 3.0 math-library problem
You need to use the Math881.h header file. It’s different from plain old math.h. That
sounds like it’s your problem.
From: chally (Mark Chally, West Covina, CA)
Subject: 3.0.1 and VBLs
Yes....VBLs DO get time when your application gets time--HOWEVER, they don’t get
time when your application DOESN’T get time--which to me seems to defeat the
purpose of a VBL. What you have to do in the case that your application needs that time
is to push your VBL (and the procedure it calls) into system memory. This is tricky
and I’m not too sure about doing it myself because I’m just learning assembly (and on a
8088 at school)...however, I do have information from Tech Support at Apple
documenting such a practice...if’ you still need the info, I can get you a copy...leave me
mail.
Oh...by the way..._DO_ get version 3.0.1 and get 2.5 megs (go for four if you can,
you’ll want {not need} it.)
From: lsr (Larry Rosenstein, Cupertino, CA)
Subject: Re: 3.0.1 and VBLs
Only the VBL block needs to be in the System Heap, in order for the VBL to get time
when your application doesn’t. The code that it calls can be in your application heap.
You have to be careful because your application doesn’t get switched in when the VBL
gets time, so you can’t rely on the CurrentA5 low memory variable. You have to stash
your application’s A5 in a place relative to the VBL block, so that the VBL code can find
it.
From: joehow (Joe Howell, Defuniak Springs, FL)
Subject: c compilers & development systems
Here is a chance for all experienced c macophiles to get on their soapbox. I am
beginning a new development project on an application development language. I have
been messing around with AZTEC C. Of all current C development systems, which is
the “best” for a full scale development project.???? thanks........joe
From: emmayche (Mark Hartman, Fullerton, CA)
Subject: Re: c compilers & development systems
Having used none of them but LightSpeed(tm) C, I can safely say that it is the best I
have ever used.
From: lnedry (Larry Nedry, Anaheim, CA)
Subject: Re: c compilers & development systems
I am hooked on Lightspeed C 3.0 Great debugger and fast turn around time from edit to
compile to run.
From: thecloud (Ken Mcleod, La Habra, CA)
Subject: Re: c compilers & development systems
I would consider MPW C for a very large project, but my personal preference is
Lightspeed C! :-)
From: adept (Roy Lovejoy, Silicon Valley)
Subject: Re: c compilers & development systems
I would have to agree on LSC 3.0x, but ONLY if there is one developer!! (try SIX some
time with it!!!)
From: rdclark (Richard Clark, Tustin, CA)
Subject: Re: c compilers & development systems
LSC is the best from the standpoint of speed, debugging, and overall usability. (MPW is
sooo slow!) However, if you need support for the latest and greatest operating system
features, then you should use MPW since Apple has been pretty good about keeping it
up to date. However, and this seems to be the consensus, I prefer LSC.
From: chenette (Philip Chenette, Los Angeles, CA)
Subject: Double Clicks
This is probably a silly question, but I can’t figure out how to detect a double-click of
the mouse. I want to open up a dialog box when the user double-clicks on an object, but
it seems there’s no event message for this. What am I missing? (Using LSP 1.11)
Thanks!
From: thecloud (Ken Mcleod, La Habra, CA)
Subject: Re: Double Clicks
You’re right, there’s no DblClikEvt... you need to compare the time and location of a
mouseUp event with those of the next mouseDown event, and if they’re sufficiently
close, the user double-clicked. Read Inside Macintosh Vol. 1, pp 255-56. If you’re
still having trouble, I can dig up some sample source code.
From: adept (Roy Lovejoy, Silicon Valley)
Re: Double Clicks
Basically, you handle double clicks in your mouse down handler, but keep a global
around that is the ‘last-when’ of the event. You then compare it with the current event
record’s ‘when’ field , and if the difference is less than the global ‘DoubleTime’ (long
int stored at $2F0.. Control panel setting) It is a double click.. (you might also want to
see if the “where”’s are within a specific range.. Hope this helps.
From: rdclark (Richard Clark, Tustin, CA)
Subject: Re: Double Clicks
The mouse isn’t supposed to move more than 3 pixels between the 2 clicks, otherwise,
it’s considered a click-and-drag operation. Also, looking at the low memory global
DoubleTime isn’t such a good idea, as Apple is discouraging any direct access to the low
memory globals. Use GetDblTime() instead. Now for some code:
#define abs(x) ((x) >= 0 ? (x) : (0-x))
Boolean IsDoubleClick(where)
Point where;
{ static Point oldLoc;
static long oldTime = 0;
long now = TickCount();
Boolean idc;
idc = FALSE;
/* First, see if the 2 clicks are close enough in time */
if ((now - oldTime) < GetDblTime())
/* They are, so see if they are close enough in space */
if ((abs(where.h - oldLoc.h) <= 3) && (abs(where.v -oldLoc.v)
<= 3))
idc = TRUE;
oldTime = now;
oldLoc = where;
return idc; }
From: emmayche (Mark Hartman, Fullerton, CA)
Subject: Re: Double Clicks and further checks
Richard is correct, as far as he goes; however, don’t forget to check that the clicks are
still within the same screen area (for example, the object on which your user will
double-click to get that dialog). If he’s real close to the edge on the first click, and
just barely outside on the second click, it shouldn’t be considered a double-click.
(I generally set a flag called checkDoubleClick in my main dispatch loop which checks
the time and object, and let the routine which handles the object decide if it was indeed
a double-click.)
From: dsa (Dave Stine, Saugus, CA)
Subject: MPW _RTExit routine
Just nailed a real weird one. I have a driver which patches the ExitToShell trap for
applications which open a communications session in said driver. This is done because
drivers running under MultiFinder don’t receive a “goodBye kiss”.
Well, it would seem that applications written in MPW C don’t call the ExitToShell code
in the normal manner; I think that in the _RTInit routine, they filch out the current
routine in the ExitToShell trap address, stash this off in some parameter block, and it
would appear that in _RTExit, they JSR (a0) to this entry point directly.
All of which means that if something patched ExitToShell *after* the _RTInit routine
has run (which is caqlled before you main() entry is), you patch does not get invoked
at program exit time. Can anyone confirm this for me, or am I just blowing smoke thru
my hat?
From: rdclark (Richard Clark, Tustin, CA)
Subject: Re: MPW _RTExit routine
Yes, MPW C is doing something strange with ExitToShell(), and it seems that patching
around the trap cannot be done. However, if you look at IM II-59, you’ll see an
“Assembly-language note” which implies that ExitToShell() calls Launch(). (And a
quick test with MacsBug seems to confirm this. However, I couldn’t see the “launch”
execution under MultiFinder -- I had to re-run the test under “flat” finder.) I dunno,
this stuff sounds pretty dangerous.
From: dsa (Dave Stine, Saugus, CA)
Subject: Re: MPW _RTExit routine
Actually, the only reason I need to have the program come thru ExitToShell() is
because MultiFlounder doesn’t call drivers with the “goodBye Kiss” that the normal
Finder does. So.... if some application has a network session open thru my driver, and
doesn’t take care to close said session before exiting, there will be some grief Real
Soon Afterwards.
So, the folks at Apple DTS told me to patch ExitToShell() to get around this
“improvement” that MF made. So I did. And now, I find that yet another piece of Apple
code has put a ditch in my path.
Yes, your suspicion about ExitToShell calling _Launch is correct -- in the nominal
Finder case. Under MF, things get much more hairy. When an application exits, MF
must tear down the “sub-heap” that was created for the app to run in, and do some
other funky things. If you want to see the beginnings of how MF launches an app, see
Goldman’s article in Aug. ’88 Byte (of all places), wherein he describes some of what
MF does. This was an e specially nice article, full of info you simply can’t get from
DTS, even if you ask. (I did)
Anyway, I have already hopped around the problem for the time being. Thanks for your
time.
From: adail (Alan Dail, Hampton, VA)
Subject: Re: MPW _RTExit routine
Rather than waiting for ExitToShell to be called for you, why don’t you just call
ExitToShell yourself when your program is done?
From: dsa (Dave Stine, Saugus, CA)
Subject: Re: MPW _RTExit routine
‘Cuz my stuff is a driver, which is being used by the application which calls _RTExit,
which doesn’t call ExitToShell().
Calling ExitToShell() for a client application from a driver often result in much
sadness.
From: rdclark (Richard Clark, Tustin, CA)
Subject: Re: MPW _RTExit routine
Whoa! If you look at the original post, it’s the App which is supposed to call
ExitToShell() -- the driver is trying to intercept THAT call so it can close itself.
However, another ugly problem rears its head -- many applications don’t use
ExitToShell(). Instead, they simply execute an RTS when done, which returns them to
a place within the Launch() trap (which then returns them to the Finder or
whatever). Time to go digging for some other way of shutting things down cleanly.