NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/sys/mac/oop/macapp3/225

Internet Message Format | 1992-12-16 | 1.7 KB

Path: sparky!uunet!stanford.edu!apple!applelink.apple.com
From: [e-mail] (ARTMA Med.Tech.B Glattfelder,AT,IDV)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Getting idle time
Message-ID: <[e-mail]>
Date: 16 Dec 92 16:08:00 GMT
Sender: [e-mail]
Organization: AppleLink Gateway
Lines: 31



>My application has a window with a number of views in it.  One of those views
>needs to get idle time so that a visual element within it can be animated.

The solution as well as the problem actually are contained in this statement:
the visual element is to be animated, so it is the one who needs to get idle
time. If it's feasible to introduce an auxiliary object deriving from
TEventHandler in your design, this is an easy way to go. I have chosen that
approach for playing movies in MacApp, where a TMovie object gets installed as
a cohandler to animate the owning view (its theater).

Of course the first candidate object to handle idle messages that comes to a
MacAppers mind is the view, but the target management of MacApp uses the same
links in its chain as the cohandlers, and because a TView object always gets
its Superview as its next handler, you would insert all the event handlers up
to the TApplication object into the cohandler chain. Whether that's a good
design is an other issue.

Now if the view really doesn't want to be target, you could probably detach it
from its superview and install it as a cohandler to the application.  I don't
encourage anybody to do so, and neither did I, but after some MacBrowse
sessions I got pretty shure that setting the fNextHandler to  nil before
calling gApplication->InstallCohandler should do the job.

Good luck

Beat Glattfelder
ARTMA Biomedical Inc.