![](/file/12652/www.mactech.com.tar/www.mactech.com/sites/all/themes/custom_front/images/you_are_here_red.gif)
![](/file/12652/www.mactech.com.tar/www.mactech.com/sites/default/files/beta-site.gif)
|
Volume Number: | 6 | |
Issue Number: | 3 | |
Column Tag: | TechNotes |
Related Info: OS Utilities
Detecting MultiFinder
By Paul Davis, Dunedin, New Zealand
Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.
Detecting MultiFinder from THINK Pascal
I am currently engaged in researching Mac language technology for the application of expert systems to the finance industry. I’ve been involved in IBM PC software since 1983, and managed the company which developed and released Pertmaster Advance, a project management package, on that platform. Since buying my first 128k Mac I’ve been interested in the potential of the Mac. With the release of the Mac II, I began working with Mac software full time.
I am convinced that OOP is here to stay, and using THINK Pascal V2.0 to explore it. After a brief exposure to MacApp I started writing a smaller MultiFinder friendly OOP application shell I’m calling MiniMac, working from the Apple demo programs OOPTextEdit and Events, the class structures of Coral LISP, Prograph, and SmallTalk; and any other Mac system class structures I can find.
While doing this, I noticed that it is useful when trying to decide how to deal with DA’s and activate events to be able to tell if MultiFinder is running, and not just if _WaitNextEvent is implemented as Apple DTS seems to think. If MultiFinder is running you can depend on resume, suspend and mouse-moved events. With just Finder running you have to use some other scheme to handle the cursor and detect whether an activate involves scrap conversion.
Noticing that one of the tech notes mentions that mouse-moved events are received as long as the mouse is outside the cursorRgn provided in a WaitNextEvent call, I wrote the following small routine. For my purposes it works beautifully.
By the way, you have to compile it into a standalone application to try it, THINK never passes my applications any app4 events while running under MultiFinder. I’ve tried it and it works great on my system: MacSE with 2.5Mb Ram, Radius 68020,68881 and TPD, System Software 6.0.3.
Explanation of the Code:
Multifinder test: hasWaitNextEvent is a boolean function set by the normal checking of the _WaitNextEvent trap described in Tech Notes and repeated below. If it is not true then MultiFinder couldn’t be running anyway. If WNE is implemented then I create a new region, which according to Inside Mac is set to a (0,0,0,0) rectangle. The mouse couldn’t be in there, so I do WNE’s with that region for kTries times or until I get an App4 (MultiFinder) event. I found that on my system I receive 4 null events before I get an App4 event so kTries of 10 works fine. You may need to experiment for an absolutely safe number of tries.
Shortcomings: You lose the first kTries events when your application is launched. This shouldn’t be critical, as applications generally flush the event queue anyway. Hasn’t been a problem for me anyway. You probably should use this routine before you put up any windows or other screen items so you don’t lose any update or activate events.
{1} function multiFinderTest: Boolean; { a little event loop to test for MF } { if MF is running we are sure to get } { mouse-moved events with a tiny region } const kTries = 10; { number of events to check for mouse event } var mouseRgn: RgnHandle; count: Integer; gotEvent: Boolean; theEvent: EventRecord; begin multiFinderTest := False; { assume false } if hasWaitNextEvent then { otherwise always false } begin debugBanner(‘has WaitNextEvent’); gotEvent := False; count := 1; mouseRgn := NewRgn; { should be empty region (0,0,0,0) } while (gotEvent = False) and (count < kTries) do begin gotEvent := WaitNextEvent( EveryEvent, theEvent, 0, mouseRgn); if theEvent.what = app4Evt then multiFinderTest := True; count := count + 1; end; DisposeRgn(mouseRgn); end; end; { multiFinderTest }
Since THINK won’t give you MultiFinder events you have to have a way to check on what is going on from outside the THINK environment. The following routine displays a little box with a message in it without messing up the event queue or MultiFinder levels like an alert did. In the above routine I insert a:
{2} debugBanner(StringOf(‘MultiFinder found after ‘,count,’ tries.’));
in the innermost if. This routine requires a WIND resource of convenient size and I use a proc of 2 though others would do. You can also use it to check the type of events coming through and debug your detection of mouse moved, resume, suspend and scrap convert events in the main event loop, none of which come through THINK. The {$R+-} is to disable/enable range checking to use the string as an array.
{3} procedure debugBanner (msg: Str255); const numTicks = 1 * 60; { seconds * ticks/sec } kResWIND128 = 128; { WIND resource } var discard: LongInt; banner: WindowPtr; oldPort: GrafPtr; lineWidth: Integer; begin GetPort(oldPort); banner := GetNewWindow(kResWIND128, nil, Pointer(-1)); if banner <> nil then begin ShowWindow(banner); { make the window visible } SetPort(banner); PenNormal; ClipRect(banner^.portRect); {$R-} lineWidth := TextWidth(QDPtr(@msg[1]), 0, Integer(msg[0])); {$R+} with banner^.portRect do MoveTo(((right - left) - lineWidth) div 2, (bottom - top) div 2); {$R-} DrawText(QDPtr(@msg[1]), 0, Integer(msg[0])); {$R+} Delay(numTicks, discard); { wait a while } DisposeWindow(banner); { get rid of window } end; SetPort(oldPort); end; { debugBanner }
Finally, for those who aren’t sure how to test for WNE, I include the following:
{4} function hasWaitNextEvent: Boolean; { determines if hardware has WNE trap } const kVersRequested = 2; { as of 6.0.1 } kWaitNextEventTrap = $A860; { trap address for WaitNextEvent } { system error constants that are missing } { from THINK interface } envBadVers = -5501; envVersTooBig = -5502; type pInteger = ^Integer; var result: OSErr; theRec: SysEnvRec; theRecPtr: ^SysEnvRec; function GetTrapType (theTrap: Integer) :TrapType; const kOSTrapMask = $0F00; { OS traps start with A0, Tool with A8 or AA.} begin if BAND(theTrap, $0F00) = 0 then GetTrapType := OSTrap else GetTrapType := ToolTrap; end; {GetTrapType} function TrapExists (theTrap: Integer) : Boolean; const kUnimplementedTrap = $A89F; { unimplemented trap value } begin TrapExists := GetTrapAddress(kUnimplementedTrap) <> NGetTrapAddress( theTrap,GetTrapType(theTrap) ); end; {TrapExists} begin hasWaitNextEvent := False; theRecPtr := @theRec; result := SysEnvirons(kVersRequested, theRecPtr^); with theRec do case result of envNotPresent: debugBanner(’64k ROMS’); envBadVers: debugBanner(‘negative version number passed SysEnvirons’); envVersTooBig, noErr: begin { good environs call, fill related fields } if machineType > envMac then hasWaitNextEvent := TrapExists(kWaitNextEventTrap); end; end; { case } end; { hasWaitNextEvent }
The above routines are incorporated in a small application which calls MultiFinderTest and then displays whether finder is running or not:
{5} program test; var multiFinderIsRunning: Boolean; begin multiFinderIsRunning := multiFinderTest; if multiFinderIsRunning then debugBanner(‘multiFinder running’) else debugBanner(‘multiFinder not running’); end. { test }
That about sums it up. Let me know if this doesn’t work in any other environments.
![](/file/12652/www.mactech.com.tar/www.mactech.com/sites/all/themes/custom_front/img/search_text.gif)
- SPREAD THE WORD:
- Slashdot
- Digg
- Del.icio.us
- Newsvine