Why the order of shutdown events is important


Try running this code:


 


PUBLIC xx


 


xx=CREATEOBJECT(“MyClass”)


quit  && quit Foxpro


DEFINE CLASS MyClass as Custom


      PROCEDURE init


            CREATE CURSOR DummyCursor (name c(10))    && create a cursor


      PROCEDURE destroy


            SELECT DummyCursor      && try to select the cursor just created


ENDDEFINE


 


 


What happens and why? On my machine, I get an error saying Alias ‘DUMMYCURSOR’ is not found.


 


You can see this behavior if you run the code in my prior post (Find which DLLs in your system are rebased) and then close VFP


 


One would expect that when the Quit occurs, the VFP process shuts down. This means releasing the public MyClass instance, which fires the destroy event.


 


The destroy event tries to find the cursor, but it has already been destroyed.


 


Apparently, probably for close to 15 years, the database engine shutdown code runs before the object manager shutdown.


 


Have you run into this issue before? Have you worked around it?

Comments (4)

  1. Hank Fay says:

    Our workaround has been/is to throw anything we want to push back in the UNLOAD into form properties, before issuing DODEFAULT() in the DESTROY, knowing that after the DODEFAULT() we won’t have the values to use. I suspect this is pretty common.

  2. cyrus says:

    I would check and see if the cursor is used before I selected it.

  3. Tod McKenna says:

    Considering destroy works from the outside in (the parent destroys before its containers), this behavior isn’t surprising.

    I’ve always thought of the destroy event as a destructor, and have avoided putting any code in it that wasn’t meant to clean up the environment or some object reference or something. That’s my work-around!

  4. Gerold says:

    Would be nice to know how this behaviour is related to or controllable by the "ON SHUTDOWN" Handler. I like the idea of having a central shutdown handler on application level that shuts down the form in a specific order if the user closes the application or shuts down the computer. Sadly I didn’t find a really mature and stable way to handle this so i have to rely on shutdown handlers on the forms.