lipa@polya.Stanford.EDU (William J. Lipa) (12/19/88)
I wonder if it would be possible for Apple to define a routine to let other applications have a time slice which could run at interrupt time. For example, if EventAvail was removed from the list of traps that may move or purge memory, an application writer could install a VBL task which did nothing except call EventAvail 60 times a second. Since EventAvail is (I believe) one of the traps which allows context-switching, this would give programmers an easy way to add preemptive multi-tasking to their applications. Since each application runs in its own heap, it shouldn't have its own memory moved or purged even if another application is run. I suppose you would get into trouble if your app was allocating a block in the system heap, though. Might there be some way around this? Bill Lipa Bitnet: lipa%polya@stanford
tim@hoptoad.uucp (Tim Maroney) (12/30/88)
In article <6120@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >No, other applications don't get time when a modal dialog is up. The way >MultiFinder senses modality is by checking then window definition procedure. >If a type dBoxProc is at the front, no other application will get time. In article <22992@apple.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >You are right that MultiFinder defines a modal dialog according to the >window kind, and not as aresult of a call to ModalDialog. (Also, not that >it doesn't matter if you are using a custom window defproc, if the kind is >the same it is also considered modal.) The kind? Are you sure? When this came up with me, it was because the "startup window" for the application I was writing stopped the MF boot sequence. That is, if the app. was one of the startup apps., once it got opened no more apps. would get launched until the user got rid of the window. The reason according to support was that I was using the modal dialog window frame; I changed to an altDBoxProc from a dBoxProc and things then worked fine. The kind field didn't change, only the definition. I think this is one of those rare cases when you're a little off the mark, Larry. >Background application *DO* get time when a modal dialog is up, provided the >foreground application yields the CPU. You mean they get time if they're marked as canBackground? Thanks for the correction! -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Do what you wanna, do what you will; Just don't mess up your neighbor's thrill. And when you pay the bill, kindly leave a little tip To help the next poor sucker on his one-way trip." - Frank Zappa, "You Are What You Is"
lsr@Apple.COM (Larry Rosenstein) (01/02/89)
In article <6129@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >the window. The reason according to support was that I was using the >modal dialog window frame; I changed to an altDBoxProc from a dBoxProc >and things then worked fine. The kind field didn't change, only the I used the wrong word. I should have said variation code. (The kind is used so infrequently, that I forgot there is a kind.) If you put up a window with variation code 1, then MultiFinder considers it a modal window, regardless of whether it is the system defproc or a custom one. Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr