shannon_cogan
asked on
Starting app threw Sub Main
Never used it before,
but lately, I have seen the light, on its little advantage.
Then again, How do you stop your application from running,
I used to simply unload all the forms... that doesn't work anymore.
I hate to use End, and I would prefer not too...
My question, how do you stop the application, without using End,
when you have started it threw Sub Main?
but lately, I have seen the light, on its little advantage.
Then again, How do you stop your application from running,
I used to simply unload all the forms... that doesn't work anymore.
I hate to use End, and I would prefer not too...
My question, how do you stop the application, without using End,
when you have started it threw Sub Main?
Is your sub main still running, Even when all the forms are unloaded?
If so, then all you need to do is put an "exit sub" in the sub main, and if all the forms are unloaded, then your app should stop too.
If so, then all you need to do is put an "exit sub" in the sub main, and if all the forms are unloaded, then your app should stop too.
I wouldn't suggest using End statement anywhere. As wford mentioned it exiting the main sub will stop your app if all the forms are unloaded. However, if you have created any objects for global use by referring to any DLL or out any class module in the project, you will have to clear all those objects by setting them to Nothing.
When your App is not terminating as expected, this is the main point I would look for. I wouldn't definitely use End statement.
When your App is not terminating as expected, this is the main point I would look for. I wouldn't definitely use End statement.
I must again make my point for using the End statement.
It is good programming practice to always put a definite ending point in your application. Especially in an event driven language such as VB. If you were to enter Sub Main() without loading any forms, call a subroutine which contains a DoEvents and that subroutine goes into an endless loop, The end of Sub Main will occur. However, just exiting Sub Main() won't stop the application in this case. Given time, I could name other instances which would have the same (or similar) results.
As far as Anita's statement that if you use End you will have to set objects to nothing, it is also good programming practice to do this anyway. Whether it's database objects, OLE objects, Device Contexts, or whatever, the rules always say:
"If you use it, put it away when you're done with it."
It is good programming practice to always put a definite ending point in your application. Especially in an event driven language such as VB. If you were to enter Sub Main() without loading any forms, call a subroutine which contains a DoEvents and that subroutine goes into an endless loop, The end of Sub Main will occur. However, just exiting Sub Main() won't stop the application in this case. Given time, I could name other instances which would have the same (or similar) results.
As far as Anita's statement that if you use End you will have to set objects to nothing, it is also good programming practice to do this anyway. Whether it's database objects, OLE objects, Device Contexts, or whatever, the rules always say:
"If you use it, put it away when you're done with it."
Just to clarify clifABB, I did not state that if you use End you will have to set the objects to Nothing. I did not mean it that way. Yes, you are right that you have to clear them always.
What I said is, in general, you need to clear any objetcs if you have created. It has nothing to do with the End statement. I have seen many times, people would have created some objects for Global use, would have the reference to some objects in some DLL but never bother to clear them by setting them to Nothing. This does causes the App and DLLs to be still in memory. Then they wouldn't know what's happening and they go and put End statement. That helps some times. But that's not the right way to do.
Generally, when all the Forms are unloaded and all the objects are cleared the App will go away without having an End statement anywhere in the Program. Of course, if you have some endless loops, then we are talking completely different issues.
What I said is, in general, you need to clear any objetcs if you have created. It has nothing to do with the End statement. I have seen many times, people would have created some objects for Global use, would have the reference to some objects in some DLL but never bother to clear them by setting them to Nothing. This does causes the App and DLLs to be still in memory. Then they wouldn't know what's happening and they go and put End statement. That helps some times. But that's not the right way to do.
Generally, when all the Forms are unloaded and all the objects are cleared the App will go away without having an End statement anywhere in the Program. Of course, if you have some endless loops, then we are talking completely different issues.
Just to clarify clifABB, I did not state that if you use End you will have to set the objects to Nothing. I did not mean it that way. Yes, you are right that you have to clear them always.
What I said is, in general, you need to clear any objetcs if you have created. It has nothing to do with the End statement. I have seen many times, people would have created some objects for Global use, would have the reference to some objects in some DLL but never bother to clear them by setting them to Nothing. This does causes the App and DLLs to be still in memory. Then they wouldn't know what's happening and they go and put End statement. That helps some times. But that's not the right way to do.
Generally, when all the Forms are unloaded and all the objects are cleared the App will go away without having an End statement anywhere in the Program. Of course, if you have some endless loops, then we are talking completely different issues.
What I said is, in general, you need to clear any objetcs if you have created. It has nothing to do with the End statement. I have seen many times, people would have created some objects for Global use, would have the reference to some objects in some DLL but never bother to clear them by setting them to Nothing. This does causes the App and DLLs to be still in memory. Then they wouldn't know what's happening and they go and put End statement. That helps some times. But that's not the right way to do.
Generally, when all the Forms are unloaded and all the objects are cleared the App will go away without having an End statement anywhere in the Program. Of course, if you have some endless loops, then we are talking completely different issues.
Anita:
My apologies, I misread what you said.
On my point, I was saying that if you put an End statement, you have a definite ending point. While and End won't always remove objects, it will stop the application including endless loops, timers, etc.
My apologies, I misread what you said.
On my point, I was saying that if you put an End statement, you have a definite ending point. While and End won't always remove objects, it will stop the application including endless loops, timers, etc.
funny, putting an end statement cause my app to crash!
It raises an error 10H in the msvb5*.dll
It raises an error 10H in the msvb5*.dll
End is a good safety, except that if it is needed then often something is wrong. At the very least I leave it out during development.
An old version of VB (1.0 maybe?) had a bug (relating to VBXs IIRC) where End would reliably corrupt memory. As a result I got in the habit of not using End. Today it's probably safe but I still shy away out of habit.
An old version of VB (1.0 maybe?) had a bug (relating to VBXs IIRC) where End would reliably corrupt memory. As a result I got in the habit of not using End. Today it's probably safe but I still shy away out of habit.
I have rethought my stand on End.
Here is a portion from VB's help file in reference to the End statement:
"The End statement provides a way to force your program to halt. For normal termination of a Visual Basic program, you should unload all forms. Your program closes as soon as there are no other programs holding references to objects created from your public class modules and no code executing."
As I am not the first (nor the second) to point out that unloading all forms will terminate an app, I will not submit this as an answer (that honour should go to wford).
I'm just pointing out that I have been convinced. :)
Here is a portion from VB's help file in reference to the End statement:
"The End statement provides a way to force your program to halt. For normal termination of a Visual Basic program, you should unload all forms. Your program closes as soon as there are no other programs holding references to objects created from your public class modules and no code executing."
As I am not the first (nor the second) to point out that unloading all forms will terminate an app, I will not submit this as an answer (that honour should go to wford).
I'm just pointing out that I have been convinced. :)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I will accept wford, as this seems to be the problem.
You all had me scared, such good points for yourselves.
Anita, thank you too... as to pin point the problem, Dlls were still in use.
You all had me scared, such good points for yourselves.
Anita, thank you too... as to pin point the problem, Dlls were still in use.
End is a good thing.
Place the end command in the Unload or QueryUnload event of your main form.