Path: utzoo!attcan!uunet!samsung!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!fuug!funic!santra!hila.hut.fi!jmunkki
From: jmunkki@hila.hut.fi (Juri Munkki)
Newsgroups: comp.sys.mac.programmer
Subject: Re: An itsy bitsy question...
Message-ID: <1991Jan9.150954.28230@santra.uucp>
Date: 9 Jan 91 15:09:54 GMT
References: <La6cV1w164w@questor.wimsey.bc.ca> <27725.2787e3d0@kuhub.cc.ukans.edu> <1991Jan8.043323.954@santra.uucp> <127611@linus.mitre.org>
Sender: news@santra.uucp (Cnews - USENET news system)
Reply-To: jmunkki@hila.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology, FINLAND
Lines: 51

In article <127611@linus.mitre.org> laf@mbunix.mitre.org (Lee Fyock) writes:
>I've found that an easier way to avoid flicker (easier than using
>background bitmaps, etc.) is to just put in a check to see if the
>mouse has moved before erasing and redrawing the line.  This is
>extremely flicker-free, with very little code.

I suggested using offscreen bitmaps so that the exclusive or mode
could be avoided. It also eliminates flicker, that is just a side
effect and IMHO, no drawing should be made until it is necessary.
If you look at the code that I included, you will see that it
checks if the mouse has moved and only then draws.

>It isn't, of course,
>very multifinder friendly.  What happens to the GetNextEvent version
>of this code if the user clicks on the multifinder icon in the
>menu bar and the program gets switched out?  It won't know it
>because app4events aren't being read, right?

The GetNextEvent in my code is only called when mouse button is
down. It has the mouseDown mask because it is possible that the
mouseUp is lost in some conditions (like when you drop into Think
C's source debugger). If a mouseup is lost, a new mouseup will
not be reported before a mousedown is delivered. All other events
are masked out. This doesn't mean that the events are simply lost.
They should be quite safe in the event queue.

The application layer can not be changed by the user, because you need
to release the mouse button before you can CLICK the menu bar. When the
button is released, our rubberbanding loop exits and the normal main
even loop is probably used for further events. The only case where
a layer change might occur is if some external program (like the
debugger) causes the change. As far as I know, Apple User Interface
Guidelines explicitly forbid behavior like this.

Using StillDown to track the loop is extremely unfriendly to other
multifinder applications. A terminal program that relies on being
called regularly might fail a download just because the user is
holding down the mouse button. (Or maybe the mouse button is pressed
down by an object that is "temporarily stored on the mouse.")

Let's put a stop to programs that fail to allow background tasking
less than 10 times per second. The only reason why an application
will not allow background tasks should be when the user is selecting
from a menu (a menu manager menu).

I hope this answers your doubts about my programming techniques.

   ____________________________________________________________________________
  / Juri Munkki	    /  Helsinki University of Technology   /  Wind  / Project /
 / jmunkki@hut.fi  /  Computing Center Macintosh Support  /  Surf  /  STORM  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~