Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amdahl!pyramid!octopus!vsi1!altnet!uunet!mcvax!ukc!s1!jrk
From: jrk@s1.sys.uea.ac.uk (Richard Kennaway CMP RA)
Newsgroups: comp.sys.mac.programmer
Subject: WaitNextEvent problem
Keywords: WaitNextEvent MultiFinder background
Message-ID: <159@s1.sys.uea.ac.uk>
Date: 14 Oct 88 15:55:01 GMT
Organization: UEA, Norwich, UK
Lines: 80


I'm having a problem with WaitNextEvent in a background application.  
InsideMac, InsideMultifinder (or whatever it's called), the few TechNotes 
I've seen, and the MPW manual don't help.  Can anyone out there?

The context:  I have written a simple application called BackgroundClock, 
which shows the current time in a little window.  MacII, System 4.3, Finder 6.0.

(By the way, if anyone can send me a MacII-compatible, MultiFinder -
compatible, everything-else-compatible, totally bomb-proof, clock-in-the-
menu-bar INIT, or tell me how to write one in C (Inside Mac says next to 
nothing about INITs and VBQ tasks), or point me to any of this information,
that would solve the problem of having a background clock ... but not the
WNE problem, which I'd like solved anyway.  I have JClock, which works with
MultiFinder on a Mac+, but crashes a MacII.)

The problem is that switching between BackgroundClock and other applications 
or DAs usually hangs the system when I switch back to BackgroundClock.

Here's some pieces of the code.  I only update the time once a second, so
to be friendly to applications, I call WNE with a 60-tick delay, in a loop
like this (MPW C):

	#define WNEDELAY	60L
		/* MPW longs are 4 bytes, I can never remember whether
		   plain ints are 4 or 2 bytes */

	while (TRUE) {
	  if (WaitNextEvent( everyEvent, &TheEvent, WNEDELAY, NULL ) ||
	      (TheEvent.what == nullEvent)) {
	    OneEvent();
	  }
	}  /* while (TRUE) */

(MPW-ers will realise that the MPW C for "TRUE" is "true".  Dont worry, I
#define TRUE to be true, because I call it TRUE on every other system I use.)

And this is OneEvent().  ClockDialogWindow is a dialog box with just a single 
statText to show the time:

	OneEvent()
	{
	DialogPtr theDialog;
	int16 theItem;	/* int16 is typedef'd as a two-byte integer */

	  AdjustClock();  /* read the clock, change the statText in the
	                     window if the time has changed */
	  if (TheEvent.what == mouseDown) {
	    DoMouseDown();  /* drags the window or handles menu commands */
	  } else if (TheEvent.what == app4Evt) {
	    if (FrontWindow() != ClockDialogWindow) {
	      SystemEvent( &TheEvent );
	        /* I think IM or some TN said to do this, I dont know why.
	           Taking it out doesnt help. */
	    }
	  } else if (IsDialogEvent(&TheEvent)) {
	    DialogSelect(&TheEvent, &theDialog, &theItem);
	  }
	}  /* OneEvent() */

If I use a 0-tick delay, then it doesn't hang (at least, I haven't seen it 
happen), but the more frequent juggling in of BackgroundClock can interfere 
noticeably with the speed of everything else.  The larger the tick-count, the 
more likely the hang.

I tried changing the boolean flags in the SIZE(-1) resource in various ways, 
but the problem remained.

SysBeep()-ing at strategic places indicates that the hang happens in the call
of WaitNextEvent() that should return a resume event when the program is
switched in.

MacsBug?  I don't understand any of the random number display it puts up.  
Is this thing documented anywhere?  Besides, life isn't long enough to use 
assembly-level debuggers...  I have tried ES-ing in MacsBug: the result is to 
kill anything *except* BackgroundClock - even the Finder.
-- 
Richard Kennaway
School of Information Systems, University of East Anglia, Norwich, U.K.
uucp:	...mcvax!ukc!uea-sys!jrk	Janet:	kennaway@uk.ac.uea.sys