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 especially 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.