Unload Form does not always terminate program execution

I've seen several cases where all of the forms in my app are closed, yet dialog boxes still pop up, indicating a problem.

This makes the users feel uneasy :-)

What is the proper way to COMPLETELY terminate execution in a VB app, after all the forms have been unloaded ?

Just make sure that after you have unloaded the form there shoud be no code in the program that makes use of the form.

I agree with Thread1. If there is a need for a form to call an object in another form, programmer must explicitly define a way so that the calling form first check if the owner of the object to be called is loaded or not.

Oddly enough, I've seen cases where a simple single-form program won't completely unload on a system running winME, but on other OS's it's ok. I used End as the last line of code after the form unloads, which seems to have solved the problem.

Well...are you sure that all forms are unloaded...? You can check it within the 'Query_Unload' evetn of the main dialog...add the following

Code:

---

Dim FormX as Form
For Each FormX in Forms
  if FormX.hWnd<> Me.hWnd then
    Debug.Print "Form is still loaded"
    Unload FormX
  End If
Next

---

Now, read these threads

http://www.codeguru.com/forum/showth...ight=avoid+end

http://www.codeguru.com/forum/showth...ight=avoid+end

and avoid "End" (unless on a very bugged Os...)



Ps:
Andreas, nice snippet ;)

Cimperiali
Yes, I know that using End isn't supposed to be good, but when you do a test like the following and the program stays in memory (seen in task manager), what then?

Code:

---

'absolutely no code whatsoever. just a blank form.
'No objects of any kind. No controls either.

---

A totally blank form compiled into an exe stays running on winME only.

So, I tried "Unload Me" and of course that didn't work. Using End in the Form_Unload sub did the trick. Sure it just terminates the program, but if it's used AFTER everything has been handled the right way anyway, then I would think it wouldn't be so bad.

Basically, I did it this way:

Code:

---

Private Sub Form_Unload(Cancel As Integer)
'set all objects to nothing
'unload any forms still loaded
End
End Sub

---

Since the form is unloading at this point anyway, what's left but to terminate?

If there's a better way to do it I'd sure like to know, as I didn't want to use End either.

I have alwasy been a major opponent of using the END statement. However, I will have to agree with WizBang on this one. The program I wrote for our company had nothing but problems on Windows ME. Out of memory errors, stack overflow, and just plain not ending properly. Things worked fine on all our 98/2000 systems. For us it was an easy decision to spend the money and upgrade to 2000. Unfortunately, this can't always be done. My suggestion is that in your VB apps, you state that will run on 98/200/XP. Leave ME out of it. But if you have to put your app on ME. please, by all means use the END.

:)

Why not get the form's address and free it?

James

Quote:

---

Originally Posted by jamesa

Why not get the form's address and free it?

James

---

And how is that done ?

and avoid "End" (unless on a very bugged Os...)

Since VB only runs on Windows, all of those OS's are very buggy.
W98 is one of the worst of the lot.

Thanks for all the great answers- it looks like End should not be used.

One of The problems with the program I am maintaining is
it has about 10 forms, and the person who wrote it iriginally, never checked for errors during executuion.
This program triggers an oscilloscope through GPIB, and if the scope probe isn't connected securely to a test point, the scope wont trigger. But the code which calls the triggering code, calls it many times.

When the scope doesn't trigger, the users typically exit the program, and restart it. When the user selects Exit from any of the Form Menus this code gets called (which is in a .BAS file)

Sub ProgramEnd(CallingWindowHandle As Long)

Dim Form As Form

' ProgramIsUnloading MUST be set here, or the forms wont be unloaded
ProgramIsUnloading = True

For Each Form In Forms
If Form.hwnd <> CallingWindowHandle Then
Unload Form
End If
Next

end sub


However, even though all of the forms are closed, the code trying to trigger the scope is still running, as verified by task manager.

So when the user runs a second instance of the program ( the old instance is running, but not visible) both programs try to talk to the scope, which results in both programs hanging.
I want to re-write the scope triggering code, so an error is returned, when the scope doens't trigger. However, that's a lot of code, so I was hoping for a quicker fix (like End, or something).

Did you stop timers and exit all loops?

Btw, Wizbang: "unless on buggy Os" =that was exactly for Windows Me,
a horrible one that I remember only for bugs...

ExitProcess seems to be a good way to end a program too, see this thread:

http://www.codeguru.com/forum/showthread.php?t=206561

I think everyone remember Windows ME as a really buggy os... :(

JeffB

It seems like the original coder failed to apply any " Exit Do " statement's
within your Looping structure's

Apply : " Exit Do " ' in your Loop's < This should basically be your pivot point ,

Code:

---

If Button = 1 then
            Exit Do
                End If

---

Apply : " Do Events "' Between your Loop's < this will allow Windows to destroy
' Your program during the Unload Event

The use of " End " in the Unload Event just forces Windows to crash exit the application , leading to an internally messy destroy .

If there is any Blitting then more than likely the original coder failed to include the necessary " Destroy DC " , in which case Windows is still trying to write into memory .

Really just guessing here , don't really know what the structure is.....

This is interesting. I made a small test program with the following code:

Code:

---

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

Private Sub Command1_Click()
ExitProcess 0&
End Sub

Private Sub Command2_Click()
End
End Sub

Private Sub Command3_Click()
Unload Me
End Sub

---

I then watched with a API spy tool to see what was happening for each button. Basically, they all call ExitProcess, but calling ExitProcess in code seems to do it more rapidly. The others had a lot of GetCurrentThreadId calls and a few Sleep 0 calls. The "X" button of the form wasn't really different either. Oddly, using End also made a call to LoadLibrary for oleaut32 and then GetProcAddress for "SysAllocString". I know the tool I use doesn't reveal everything, so maybe someone else can add to this.

Very interesting.
Now, what happens if you have a project that instantiate a dll, and before
releasing you try the different kind of exit?

[QUOTE=Cimperiali]Did you stop timers and exit all loops?


Not explicitly. The form that is sending the commands to the scope is still running.
My understanding of unloading a form, is that all code executing in a form is out of scope, once the form is unloaded.

Since my ProgramEnd() unloads all forms except the calling form, I expected that to take care of all running code.

Bad assumption, I guess.

Not true: loop or timers could keep your form alive, preventing unloading
(well, matter is what you do inside loops or timers event...)

Better you exit the loops and stop the timers -expecially Api timers...

For example (the thing is due to the doEvents...)
unloading form that has the following code (timer interval 200 ms)
will not stop program - in ide and in compiled (you will have to
terminate it hitting the square button in ide[=taht is an "End"!]
or using task manager if running a compiled...[that should be an
ExitProcess...], even if you do not see the form.

Code:

---

Option Explicit

Private Sub Timer1_Timer()
  Static Counter As Long
  Counter = Counter + 1000
  Call loopme(Counter)
 
End Sub
Private Sub loopme(ByVal Counter As Long)
 Dim lstop As Long
  Do While Counter > lstop
      DoEvents
      Me.Caption = "Hi!" & Counter
      lstop = lstop + 1
  Loop
End Sub

---

Code:

---

'stop it this way....

Option Explicit

Private bQuitting as Boolean

Private Sub Timer1_Timer()
  Static Counter As Long
  If bQuitting Then
          Timer1.Enabled = false
          Exit Sub
    End If

  Counter = Counter + 1000
  Call loopme(Counter)
 
End Sub
Private Sub loopme(ByVal Counter As Long)
 Dim lstop As Long
  Do While Counter > lstop
      DoEvents 'after this,other  messages are processed...!
      If bQuitting Then 'So here bQuitting may be changed...here you can get it!
          Exit Do
      End If
      Me.Caption = "Hi!" & Counter
      lstop = lstop + 1
  Loop
End Sub

Private sub Form_queryUnload(...)
    Timer1.Enabled = False
    bQuitting= True
end sub

---

It just occured to me what might be the reason for the Sleep 0 calls I see when a vb program unloads. Could this be the API equivelent of DoEvents? Maybe later when I find the time I will do a few tests. However, the API spy tool I use is almost certainly leaving out some things. Any suggestions on good tools to use would certainly be helpful in sorting through all this.

I don't think it's the equivalent of DoEvents, I think it's just a way to let the system execute other exe and threads and return as soon as possible to the program. I think DoEvents would look more like this:

http://www.vbcodelibrary.co.uk/modul...c=1204&forum=3

Anyway if you find anything I would like to know more too.

JeffB

Click Here for : API SPY !

Quote:

---

Originally Posted by WizBang

It just occured to me what might be the reason for the Sleep 0 calls I see when a vb program unloads. Could this be the API equivelent of DoEvents? Maybe later when I find the time I will do a few tests. However, the API spy tool I use is almost certainly leaving out some things. Any suggestions on good tools to use would certainly be helpful in sorting through all this.

---

Quote:

---

Originally Posted by cappy2112

Thanks for all the great answers- it looks like End should not be used.

One of The problems with the program I am maintaining is
it has about 10 forms, and the person who wrote it iriginally, never checked for errors during executuion.
This program triggers an oscilloscope through GPIB, and if the scope probe isn't connected securely to a test point, the scope wont trigger. But the code which calls the triggering code, calls it many times.

When the scope doesn't trigger, the users typically exit the program, and restart it. When the user selects Exit from any of the Form Menus this code gets called (which is in a .BAS file)

Sub ProgramEnd(CallingWindowHandle As Long)

Dim Form As Form

' ProgramIsUnloading MUST be set here, or the forms wont be unloaded
ProgramIsUnloading = True

For Each Form In Forms
If Form.hwnd <> CallingWindowHandle Then
Unload Form
End If
Next

end sub


However, even though all of the forms are closed, the code trying to trigger the scope is still running, as verified by task manager.

So when the user runs a second instance of the program ( the old instance is running, but not visible) both programs try to talk to the scope, which results in both programs hanging.
I want to re-write the scope triggering code, so an error is returned, when the scope doens't trigger. However, that's a lot of code, so I was hoping for a quicker fix (like End, or something).

---

It seems to me that there is something wrong with the code.. What is that CallingWindowHandle suppossed to mean in the code? Could you post at least one of that Exit menu routines?

Thread1, if you are unloading all forms from a Query_unload or Unload event of
a form, it make no sense to trig the unload twice by cycling throug all forms:
you can skip the one from which you triggered the unloadAll code, which is already
unloading
enche:
CallingWindowHandle has inside the Hwnd of the calling -and already unloading-
form. ie:

Code:

---

private sub form Query_Unload(...)
  call UnloadAll(Me.Hwnd)
end sub

Public sub UnloadAll(byval CallingWindowHandle  as long)
  dim frm as form
  for each frm In Forms
      if frm.hwnd<>CallingWindowHandle  then
            unload frm 'all but the caller, which is already unloading -
                      'else its unload event will trig again...
      end if
  next
end sub

---

Crystal clear Cimp thanks for that :D.. Apology.. I just thought there is a User menu, named Exit, in the form and the Sub is being called there.. :)

Quote:

---

Originally Posted by Thread1

It seems to me that there is something wrong with the code.. What is that CallingWindowHandle suppossed to mean in the code? Could you post at least one of that Exit menu routines?

---

Cimperiali is correct.

The code I posted gets called from QueryUnload, in every form in the project.
The CallingWindowHandle is the handle of the form which calls the code to unload all of the forms. I don't want the Unload event for the calling form, to get triggered again.

Quote:

---

Originally Posted by Cimperiali

Not true: loop or timers could keep your form alive, preventing unloading
(well, matter is what you do inside loops or timers event...)

Better you exit the loops and stop the timers -expecially Api timers...

---

I agree with you.
I've just looked at the project again- and the code which triggers the scope is called from at least 10 different places, which means I would have to check for the unload event (via a global flag) from many, many places.

I tried a fix, but ended up with lots of variables not defined ina With block problems.

At this point, it would just make the code more messy than it already is.
I don't want to hack into that now. I'll have to think about another way to keep the app from restarting, once all of the forms are closed.

Hmm- how about this, if queryunload is called, I can set a ProgramIsUnloading flag, and check to see if it is set in FormActivate, or FormLoad. THis should keep the forms from reappearing, but wouldn't stop the code that is talking to the scope.

What do you think ?