DN5@psuvm.psu.edu (04/09/90)
Hi: I need to be able to close a MacApp window from a button placed within that window. I have tried using the .Close method, but the system crashed on me. My current way of doing this is to have a global variable which is normally NIL, but if non-NIL contains a window (gWindowToClose), and whenever my application sees that this is non-NIL, closes the window. I think that there should be an easier way of doing this. Perhaps the PostEvent solution mentioned in an earlier message? D. Jay Newman dn5@psuvm.psu.edu
keith@Apple.COM (Keith Rollin) (04/10/90)
In article <90099.091150DN5@psuvm.psu.edu> DN5@psuvm.psu.edu writes: >Hi: > >I need to be able to close a MacApp window from a button placed within >that window. I have tried using the .Close method, but the system crashed >on me. My current way of doing this is to have a global variable which >is normally NIL, but if non-NIL contains a window (gWindowToClose), and >whenever my application sees that this is non-NIL, closes the window. > >I think that there should be an easier way of doing this. Perhaps the >PostEvent solution mentioned in an earlier message? D. Jay, It sounds like you are doing the right thing by calling the .Close method. If you need to close a window such as a dialog, then you just say "aWindow.Close;". If this isn't working then it sounds like you need to do some more tracking down of what is going on. For instance, where are you crashing? In MacApp's code? In yours? Why is it crashing? What is the error number or message? What can you track down by using the MacApp debugger, SADE, Macsbug, TMON, Jasik's Debugger, or the THINK debugger (if you are using THINK Pascal). Using "gWindowToClose" or posting a command are both creative solutions, but neither should be necessary. (Note: I've helped people with questions concerning odd crashing in MacApp in the past. In almost every case, it's because they were calling UnloadAllSegs when there were return addresses to non-permanently resident segments on the stack. Could this be the case?) -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
strasser@psych.psy.uq.oz (Michael Strasser) (04/11/90)
Are the flags for the window set correctly? I had some problems with a window bombing once because I hadn't specified its 'view' resource properly, viz: dontFreeOnClosing and doesntCloseDocument. Your problem may be similar. I hope this helps. Mike Strasser Psychology Department University of Queensland AUSTRALIA
DN5@psuvm.psu.edu (04/11/90)
In article <435@psych.psy.uq.oz>, strasser@psych.psy.uq.oz (Michael Strasser) says: > >Are the flags for the window set correctly? I had some problems with a >window bombing once because I hadn't specified its 'view' resource >properly, viz: dontFreeOnClosing and doesntCloseDocument. >Mike Strasser I believe that the flags are set properly: freeOnClosing, and closeDocument! When the window closes, I want the document and window closed and freed. Perhaps my trouble lies in the fact that if the window is freed when I call the SELF.GetWindow.Close, then any further processing that MacApp does to that window causes bombs. D. Jay Newman dn5@psuvm.psu.edu
rick@jessica.Stanford.EDU (Rick Wong) (04/12/90)
Another possible cause of your problem is that you may be trying to free the window while one (or more) of its methods is still executing. In par- ticular, the window's mouse-handling method may be calling your button's mouse-handling method. If closing the window frees it and its document, any still-executing methods of any freed objects will be left referring to invalid objects. If they subsequently try to change any no-longer- existent fields, they will whomp over random parts of memory, thus causing a crash. To work around this, you can set a global flag indicating the window should be closed. You can periodically check this flag in your application's DoIdle method, where you should be able to safely free the window and its document. Or, you could wait for the PostCommand mechanism in some forth- coming version of MacApp. Rick "no snazzy .signature" Wong rick@jessica.stanford.edu