cpyang@ccnysci.UUCP (Chao Ping Yang) (04/01/89)
I have written an application that sets up the VBLTask to collect data once a few seconds, so I can play with the data while more is collected INSIDE my program. But then sometimes I want to do other things, simple but OUTSIDE... If I were still in the DOS world(I thought the Mac is better so I switched), I could invoke a second copy of the command processor so that I can do all the DOS things while the data is collected in the background. So the application Terminate & Stay Residence. Can somebody tells me how to do this in a Mac? In other words, how do my application runs in the background so I can use the Finder without using Multifinder? Thanks in advanced. -- ==Chaoping cpyang@ccnysci.bitnet
ech@pegasus.ATT.COM (Edward C Horvath) (04/01/89)
From article <1474@ccnysci.UUCP>, by cpyang@ccnysci.UUCP (Chao Ping Yang): ... > If I were still in the DOS world(I thought the Mac is > better so I switched), I could invoke a second > copy of the command processor so that I can do all > the DOS things while the data is collected in the background. > So the application Terminate & Stay Residence. > > Can somebody tells me how to do this in a Mac? In other words, > how do my application runs in the background so I can use the > Finder without using Multifinder? The simplest answer is to write a driver, either as a Desk Accessory or as a facility launched by a cdev (control panel item). The former typically have a window so that you can exercise control over them at any time, the latter remain in background and have to be summoned with the Control Panel DA. Of particular interest to you will be the accRun control call, which any driver (not just DAs) can sign up for. While there is no guarantee of how frequently you'll get the processor (only when the application calls SystemTask), you get control under "clean" conditions, with the whole toolbox and OS available. There are lots of restrictions with the use of a VBL task, since you can't do ANYTHING that may move or purge resources. The real drawback to using drivers is that you always enter and exit "through the top," i.e. you must retain any state information in explicit variables. This contrasts with the way of an application under Multifinder, which has its own stack and can relinquish control anytime, and without unrolling the stack, by calling WaitNextEvent (or GetNextEvent, or EventAvail). Hope that helps; see the Device Manager section of Inside Mac II for more info. =Ned Horvath=
beard@ux3.lbl.gov (Patrick C Beard) (04/06/89)
A recent BYTE issue covered the ins and outs of writing INITs, CDEVs, and
other ilk. This is the best method for installing code that hangs around
for subsequent use. I find that the best way to load this code is to
use a separately compiled code resource of my own type, set the system heap
bit, GetResource & DetachResource, and hook the data collection part into
VBL. Patch a trap like SystemTask to get time from the system to for example
open a file and write the data to it. Then use your application to merely
examine the data file. Use a CDEV to control the behaviour of the code.
Anyway, check out that issue of BYTE. A couple of months back.
+----------------------------------------------------------------+
\ Patrick Beard "Badges? \
\ Berkeley Systems, Inc. I ain't got to show you... \
\ PCBeard@lbl.gov ...NO STINKING BADGES!" \
+ ---------------------------------------------------------------+