[comp.sys.mac.programmer] MacApp help needed

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