ADVERTISEMENT

Related Info: OS Utilities

Detecting MultiFinder

By Paul Davis, Dunedin, New Zealand

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.