vb6 slow shutdown

[jlbenson]

I have written a rather large program in vb6 that takes forever to shutdown...I'm mean on the order of minutes! I have tried everything I know to make it shutdown faster, including unloading all the forms etc. I ultimately use the "End" statement to do it, but it still takes too long. A previous version of this same program in vb3 shutdown "instantaneously". ?? Can anyone enlighten me on this?
I can shut this program down and it may remain in the running programs list that you get with "ctrl-alt-del" for 2 or 3 minutes or more.
I would appreciate any help I can get on this.
Thanks,
JB

[ShawnDev]

Put some MsgBox prompts in the various events that fire on shutdown. That may help you narrow down a bit where the lag is occurring.

Is there code that's doing anything in those events?

[jlbenson]

Shawn,
Thanks for the quick reply, but as far as I know, nothing "fires" on the shutdown event. I just have a button on a form that has an "End" statement in it. I do have some fairly large arrays, but I even tried erasing them manually before the End statement. That didn't work either. It's my understanding that End is supposed to immediately terminate the program just as it did in vb3. ??
JB

[JeffB]

END close the program immediately, destroying variable, but not OBJECT REFERENCE, if you have any object that reference to whatever, make sure you use SET objObject = nothing. Also, the END don't call the QueryUnload event and the Unload event, make sure you Unload formName each form of your projects. Make sure each class and .dll are destroyed by you, the END statement will not do it.

JeffB - hope it helps

[jlbenson]

JeffB,
Thanks. I did unload all forms and set them to nothing, but I may have some other objects I reference that I have not specifically addressed. I will try that. Is there any other way to "bail out" of a vb6 program without looking through thousands of lines of code I wrote a long time ago and make it stop "right now"?
Thanks,
JB

[JeffB]

You can use that:

Private Declare Sub ExitProcess Lib "kernel32" (ByVal uExitCode As Long)

Private Sub Command1_Click()
    ExitProcess 0
End Sub

You CAN use that, but it is not the GOOD WAY to do it , well, it may not work 100%, if so you may take a look at TerminateProcess and GetCurrentProcessID.

I am not responsible for any problem encoutered by using that code

JeffB - hope it helps

[jlbenson]

JeffB,
Thank you, thank you, thank you! You're a genius! That appears to work.

[ShawnDev]

as far as I know, nothing "fires" on the shutdown event.

With the exception of calling End (thanks Jeff - I didn't know End bypassed all that) - or ExitProcess, etc. - a VB program will typically fire the Query Unload and Unload events when it is shut down.

I had previously understood that it would also fire the Deactivate, LostFocus, Terminate, etc. events but I learned last night that I was mistaken.

Using ExitProcess (as Jeff has noted) is really a crude club and probably not the best solution. What I would suggest is to put a breakpoint on End and then use the debugging tools to try to determine what might still be running and/or loaded.

[jlbenson]

Shawn,
Thanks for the input, but Jeff's "crude club" really works well. This is a stand-alone project that doesn't interact with other apps. I just want to kill it. I don't really care what it does after I say "quit". If I had time to make it end "elegantly" I would.
JB

[JeffB]

Since it seems like a crude club, here what MSDN say about ExitProcess:

From Microsoft MSDN
ExitProcess is the preferred method of ending a process. This function provides a clean process shutdown. This includes calling the entry-point function of all attached dynamic-link libraries (DLLs) with a value indicating that the process is detaching from the DLL. If a process terminates by calling TerminateProcess, the DLLs that the process is attached to are not notified of the process termination.

Since it exit the current process, it's like an END, but in better. TerminateProcess would be a less good way to end, but in anyway, looking MSDN, ExitProcess seem to be a good way to Exit an application. Let us know if you encounter any strange problem using ExitProcess.

JeffB

[jlbenson]

JeffB,
Thanks again. I feel even better about it now!
JB

[ShawnDev]

Thanks for clarifying Jeff. It was TerminateProcess that I was thinking of. It's been a year or so since I've had a situation where I had to concern myself with these issues (and in that case I was trying to kill application A from application B). ExitProcess should be fine. TerminateProcess was the "club" I was thinking of.

[yolip]

Hi JeffB,

I tried the following code you given but it also terminate my VB even it is in debug mode.... any solution

Private Declare Sub ExitProcess Lib "kernel32" (ByVal uExitCode As Long)

Private Sub Command1_Click()
ExitProcess 0
End Sub

[JeffB]

Since it is VB6 who is running your application, it is VB who is ending. There is nothing you can do about how the API works, but there is many way to make your application work differently depending of if it is in developpement mode or not. You could use a commandline parameters, conditional compilation or using simply a private variable (which should be easier):

Option Explicit

Private Const MODE_DEV = 0
Private Const MODE_EXE = 1

'You just need to change this value when compiling your EXE
Private Const mode = MODE_DEV
'Private Const mode = MODE_EXE


Private Declare Sub ExitProcess Lib "kernel32" (ByVal uExitCode As Long)

Private Sub Command1_Click()
    If mode = MODE_DEV Then
        End
    ElseIf mode = MODE_EXE Then
        ExitProcess 0
    End If
End Sub

Of course, it means you will not be using ExitProcess in debug mode. If your program don't terminate normally, you you can use VB to stop your application in developpement mode and when you compile, by changing the value of the variable, you will have an EXE that end with the ExitProcess API.

JeffB

[jlbenson]

JeffB,
That's exactly the technique I have been using since you first gave me this ExitProcess idea a long time ago. It works great.
Thanks again,
JB