I want to trap the last event in a VB application
that is this event should catch END statment
The reason i need to release some vectors in a dll being used in this application
Printable View
I want to trap the last event in a VB application
that is this event should catch END statment
The reason i need to release some vectors in a dll being used in this application
End is what is says, End. There is nothing after that.
Don't use the end command, but unload your forms. This way you can use either the form unload or queryunload events.
what happens in case of an abnormal termination so i need to know when end was called
You need to do error trapping to catch an error and deal with that way it your subroutines.
ie
Sub FUNC()
On Error Goto XYZ
...
Exit Sub
XYZ:
do what you need to here. for error handling
and kill the program if needed.
End Sub
Well i have crossed the stage of error trapping now iam in trapping the End Statement Give me a different idea please.
Anywhere in the code of the project i can say End
but i need to trap it somewhere
well If you want to know which End you call you can do something like this:
Now istead of calling End call My_EndCode:
Sub My_End(byVal reason As String)
Call MsgBox(reason) '' do what you want to here
End
End Sub
is this what you want?
C'mon ppl
I need something like ExitInstance in VC++
hah int ExitInstance() in VB... funny. this is used in Multithreaded Apps.
Post some code so we can see what you are trying to do and what you need to do.
I didnt u didnt read it fully ..
I want an equivalent of ExitInstance() function in VC++ in VB
Exactly how many "End" statements have you got in your app. Hopefully only one or two occurances plus the usually Unload Event. If you are hard coding "End" statements then put in a msgbox above each occurance something like :-
MsgBox Str(Err) & " : " & Err.Description
End
I don't quite understand your problem, if exiting on an End then the code must execute the End, this ain't a random event.
Forms have a Terminate Event to which you can write a routine.
ie Public Sub MyForm_Terminate()
This is called AFTER the form has unloaded and I believe is also run when you do an END statement. It also covers the External Terminate as well but don't quote me on that.
If you use the End statement, no other event is generated.
If you use the Unload <form> statement, you first get the Query_Unload, then the Form_UNload event, and finaly the Form_Terminate event.
NEVER use the End statement, it's a bad programming thingie imho.
Here it is we generate VB code from VC++ application then the user can make changes whatever they want.. But i cannot tell the users that wherever they put End they should put our code instead if i can get control on End of application i will do some processing .. Saving some details for loading later @ the same stage where it is currently..
Sounds funny but this is what it is
Hmmm.doesn't sound funny just sounds confused. If you are so impressed by this VC++ routine, why not swap your app over to that language.
BY the way use of the "End" statement is not bad coding!!!!!!!! In the same way that the old goto was considered bad in college, but not in the really world when ya had to write applications that were speed dependant :)
Personally l avoid End, cos l like to release all resources in the Unload/Terminate events of forms. :0
Switching over to VC++ is not a solution.
But if i can do it in VC++ (getting the event)
Why cant i get the event in VB..
There will always be a way out
Oh if this were only true.Quote:
There will always be a way out
There are always things that can be done but there isn't always a way out.
You can find shortcuts and workarounds... but they are different to ways out.
If you cannot educate people in the use of the "End" Statement then you are overlooking the "way out".
If you want to detect outside closure then the current VB Events quite nicely cover ALL of the possibilities and can even stop a VB from being killed by the Task Manager if required.
You work with the tools you have and those tools were designed for people who know what they are doing... if you want to stop someone from throwing in End statements here, there and everywhere then you are breaking the spirit in which VB was created in the first place.
And that isn't a way out :D
Well I can say only one thing
This is a requirement
Beggars cant be chooosers
So I need an event Hook or Crook....
So what again was the initial problem...why not step through the program in debug an see what is happening. :)
First, every Program when it is terminated goes through the exit routines, even if it is terminated through the task manager. If, however a GPF is thrown, there is nothing you or anyone can do, even in C++. When the OS decides to take the great plunge, and kills itself and the program, your screwed. So, all you have to do is place what ever you are looking to do in the exit routines of your main form. The Form_Unload event even has a cancel property you can use to stop the exit conditionally. So as long as the program does not GPF, or the user has not arbitrarily turned off the PC, you can catch it. The three events are:
QueryUnload
Unload
Terminate
Second, yes, the end statement is bad coding, unless of course you like memory leaks. Using the end state leaves allocated memory unaccounted for. As long as the program is small it makes no difference, but when you get into real programming, with multiple classes, object brokers, and other OOP techniques, you need to use the unload commands, so you can clean up the program on the way out. If you don't the user gets the infamous "Out of Memory" error. Goto statements are also bad coding. Spaghetti code should be avoided at all costs. The only exception to that is the error handling routines used today in VB. However, those will shortly go away, as VB 7 has built in structured error handling, using the Try...Catch...Finally architecture familiar to Java and C++ programmers.
But what i need is a solution to this if i can do it in VC++ why not in VB
Does this mean you are trying to make a decompiler so that the user can alter your code. If it is, why are you woried about the end statement, you should be more worried about the other 92 million ways a bad programmer can wreak havok in an app if let loose at the source code. All you do is write a big disclamer on the box.Quote:
Here it is we generate VB code from VC++ application then the user can make changes whatever they want.. But i cannot tell the users that wherever they put End they should put our code instead if i can get control on End of application i will do some processing .. Saving some details for loading later @ the same stage where it is currently..
Sounds funny but this is what it is
Actually we generate vb forms from our application when the user starts or rather let me say access our ActiveX controls(Ours i mean the controls we developed at our office) we initialize certain variables , Now the user calls end i should either release or save values. Both of which iam not doing since i dont get controls. I cant do any where else since this has to be the last thing to be done .
So here we go again i need to get control on End statement.
Back to Square One
Your activeX controls will unload themselves properly as long as they're compiled, as it happens so will the form and everything, It's only when it's not compiled that thing's don't fire properly.
I think you're getting mixed up between what you would like and what you need. As far as I know, there's no way to trap that. How do you trap an exit(0) in C? If you want to trap data on an end, I'd go with the suggestion that you write your own end function. If I wanted to trap data in C whenever I called exit() I'd make a trap_exit(int x); and take care of it myself. It's good programming to do that if you need the data so why not tell people that they need to use it if they want to trap the data?
Hello everyone! It's been a long time since I've been here (a harddrive and a headache later - maybe more than one headache...but anyways...) - I don't know if you've thought of it... the idea is rather simple, but just in case you hadn't thought of it... if you need to save value then couldn't you store the value(s) in a file on the computer?? Whenever the value(s) change update the file. As for releasing them, well they're gone once you end the program. I don't know, like I said - maybe that's too simple, but if I'm understanding correctly - I think it would work without having to trap the End statement... Just a thought!
Cougar
A couple of points.
1. If you are releasing activex controls to your clients, which they incorporate into vb projects then it is their problem if they use End statements. In the same way if you release a financial app and the end user refuses to following the instructions, then no amount of tweaking the code will fix it.
2. Chockenberry have you ever worked in the real world. Yes GoTo leads to bad code if it is applied without defined standards. Try explaining to a Bank that you have just slowed down their systems through removing all GoTos from their programs. In some cases you need the speed of GoTos, you don't want the GoSubs because of extra lines of code being executed. The first job l had as a programmer was for a bank maintaining COBOL code, yes it was fill of GoTos. The GoTos were used to speed up processing.
I am very confused about what exactly the problem is or what you are trying to do but here are some topics to review in the help:
OpenProcess
GetExitCodeProcess
Like I said I am still confused so if this is far from what you are looking for oh well.