Partager via


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

  • Anonymous
    August 07, 2007
    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.

  • Anonymous
    August 08, 2007
    I would check and see if the cursor is used before I selected it.

  • Anonymous
    August 08, 2007
    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!

  • Anonymous
    August 21, 2007
    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.