mikeoro@hubcap.clemson.edu (Michael K O'Rourke) (05/25/89)
First, let me say thanx to all the people who responded. You all told me the same thing. That i needed to lock my CODE resource. Guess what? It already is locked... but that made me try something else. Here is the real problem that i found. If i put in a little while not button loop in below where i install the VBL, the program works! I wait and sure enough 3 seconds later (i set vblcount to 180) it beeps. Then i hit the button and the program exits. No loop, no go on the program. It dies and I get and call to MacsBug with a DeQueue error. What's that? Anyway, why would the machine crash if the installing program exits before the VBL task comes up to go? I tried allocating my VBLTask record as a handle and locking it in case the fact that it got disposed of was the problem, but this didn't help. Your help is graciously requested, Michael O'Rourke
ksitze@nmsu.edu (Kevin Sitze) (05/25/89)
In article: <mikeoro@hubcap.clemson.edu's message of 24 May 89 23:36:35 GMT> Michael writes: >Anyway, why would the machine crash if the installing program exits before the >VBL task comes up to go? I tried allocating my VBLTask record as a handle >and locking it in case the fact that it got disposed of was the problem, but >this didn't help. Read this again. Your problem lies in the fact that your exiting your program before dequeueing the VBL task. In other words, your entire application heap has suddenly gone to vapor-land and since the VBL manager is trying to run a task in this invalid region of memory, where there no longer is a task, the machine decides to upchuck it's problems directly to the user. The answer to your problem is to allocate the resource into the system heap. Go into ResEdit and enable the 'allocate in system heap' (?InSysZone?)flag for that resource. You shouldn't have any problem from there. -Kelesi -- +--------------------------------------------------------------------+ | From the Macintosh of: Kevin L. Sitze. This is ME: ksitze@NMSU.edu | +------------------------------------------------------+-------------+ | The difference between intelligence and stupidity is | Is this | | that intelligence has a limit. -- anonymous | better? | +------------------------------------------------------+-------------+
tim@hoptoad.uucp (Tim Maroney) (05/27/89)
In article: <mikeoro@hubcap.clemson.edu's message of 24 May 89 23:36:35 GMT> Michael writes: >Anyway, why would the machine crash if the installing program exits before the >VBL task comes up to go? I tried allocating my VBLTask record as a handle >and locking it in case the fact that it got disposed of was the problem, but >this didn't help. In article <KSITZE.89May25072657@bonito.nmsu.edu> ksitze@nmsu.edu (Kevin Sitze) writes: >Read this again. Your problem lies in the fact that your exiting your >program before dequeueing the VBL task. In other words, your entire >application heap has suddenly gone to vapor-land and since the VBL >manager is trying to run a task in this invalid region of memory, >where there no longer is a task, the machine decides to upchuck it's >problems directly to the user. Sorry, no. One of the many things that happens as a result of ExitToShell or (exec-type) Launch is that all VBL tasks in the caller's application heap are dequeued. There's no more need to dequeue your own VBLs than there is to close your own resource files. >The answer to your problem is to allocate the resource into the system >heap. Go into ResEdit and enable the 'allocate in system heap' >(?InSysZone?)flag for that resource. You shouldn't have any problem >from there. Only if you want it to run forever. Most application-launched VBLs should want to stop running when the application does. -- 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"