Printable View
Hai pals,
Even after executing the code this code, my application exe is still running in the task manager?
Code:Option Explicit
Private Sub cmdExit_Click()
Dim frm As Form
For Each frm In Forms
If frm.Name <> Me.Name Then ' Unload this form LAST
Unload frm
Set frm = Nothing
End If
Next
Unload Me
End Sub
what can be the problem?
Leaving OBJECTS open (not set to NOTHING explicitly)
Calling ANY form property after that code.
We'd have to see more...
ahaaa, let me chk.Quote:
Originally Posted by dglienna
Try moving the code to the Unload Event instead of from a command button.
no tom,
it just the system tray program exit menu item. btw, i am keep chcking for any objects not destroyed.
If you don't mind being a little messy . . . Put an "End" Statement after your loop. That oughta shut her down.
That's WRONG. END should NEVER be used. It is old, from the DOS days, when full-screen apps wouldn't shut down. END still leaves open files open.
I would not say that end should never be used. There is no problem using it but one should clean up the proper way before hand even if the End statement is used. End will terminate the app and in most cases there are no adverse side effects. Now of course if you leave files open and dlls initialized there could possibly be an issue but even then in most cases they are terminated by the end statement pending data will likely be lost but that is about it.
As for why the app is not shutting down my guess would be due to code located in a module or class that is part of your project. The end statement should terminate the process but would be better to look for the real problem.
I woudl check modules,classes, the unload event in each form, check the form area declarations for vars defined as public which may be accessed in a module and things such as this.
very useful information i got !
Code:Option Explicit
Public xlAppTemp As Excel.Application
Public xlWorkBook As Excel.Workbook
Public xlSheet As Excel.Worksheet
Dim strDate$
Public Sub GenerateReport()
On Error GoTo ErrHandler
' Creating Object for Excel File.....
Set xlAppTemp = New Excel.Application
' Making it Invisible and non-Interactive.....
xlAppTemp.Visible = False
xlAppTemp.DisplayAlerts = False
' Opening Template Excel File.....
Set xlWorkBook = xlAppTemp.Workbooks.Open(App.Path & "\Book1.xls", , False)
Set xlSheet = xlWorkBook.Sheets(1)
' Making Active to Worksheet 1.....
xlSheet.Activate
' END ' Let's put END here. Think EXCEL will end also?
' I am doing lot of things in it, but to provide you with example
xlSheet.Cells(15, 1) = "This is my report 1"
' Formating Date to attach with new file name.....
strDate = Format(Date, "yyyy-mm-dd")
' Saving excel file with new name on different folder.....
xlWorkBook.SaveAs App.Path & "\Output" & strDate & ".xls"
Cleanup:
' Destroying Objects.....
Set xlSheet = Nothing
xlWorkBook.Close SaveChanges:=False
Set xlWorkBook = Nothing
'The Visible and DisplayAlerts settings should be reset, as they can affect 'manual' use of Excel too.
xlAppTemp.Visible = True
xlAppTemp.DisplayAlerts = True
xlAppTemp.Quit
Set xlAppTemp = Nothing
Exit Sub
ErrHandler:
'I presume this section comes after ErrHandler, in which case you will want to close the workbook without changes.
'(save happens just above if no error occurs)
xlWorkBook.Close SaveChanges:=False
Set xlWorkBook = Nothing
'The Visible and DisplayAlerts settings should be reset, as they can affect 'manual' use of Excel too.
xlAppTemp.Visible = True
xlAppTemp.DisplayAlerts = True
xlAppTemp.Quit
Set xlAppTemp = Nothing
End Sub
Private Sub Command1_Click()
Call GenerateReport
Beep
End Sub
No. I would say that it will not. but then here you are activating another program and should not expect the end statement to terminate the external executable(s).Quote:
xlSheet.Activate
' END ' Let's put END here. Think EXCEL will end also?
That is not to say that end does not have its uses. As with all tools they are good for some things and not for others. One must no where and when to use them and what to expect when they are used.
In this case the program that you have written should terminate completely but will leave Excel running as should be expected and in rare cases maybe even the desired effect.
That said I rarely use such coding practice. I do not like the idea of forcing my users to purchase excel or other third party programs to use my software. It has its place but you also must realize there are special requirements when you use these techniques that are outside of the VB environment.
But, called enough times in a row is a guaranteed way to run out of memory.
An instance of Excel is created, and it's under program control to terminate it properly. That is the ONLY way to release the memory it's using.
You say "it just the system tray program exit menu item. btw, i am keep chcking for any objects not destroyed."
Do you mean you are exiting the program from a pop-up menu from the system tray? If that is the case you still should put the unload forms code in the Unload Event. Try it.
I apologize if I misunderstood.
Yes of course, but this is not the purpose of the end statement. There is a specific statement to terminate the external instance of the other program you have started in this case. In other cases there may be no direct method to shut down the other program. Shell to a dos program for example.Quote:
Originally Posted by dglienna
BTW one can always simply close excel manually at any point.
The point is that just because the End statement does not terminate external programs launched by your code does not mean that it should never be used. That's kinda like saying one should never use the unload function because it does not unload the entire app or not use the print function because it does not cause a word document to print on a different pc. Or you could say that one should never use the excel functions or word or access because they don't terminate when your application is closed.
The fact is the End does exactly what it should. It ends your program execution. It is up to the programmer to make sure that the program is ready to be ended at this point but the VB environment does handle many oversights by the programmer as well as many bad programming techniques to result in a clean exit in most cases. It was never intended to end other programs.
I had one app which would terminate just fine on most machines, but not all. It was a simple app, with only one form. After exhausting all options, I used the End statement after Unload Me, and that solved it. I think that was with winME though, but it just shows that it is possible to have an app not fully unload even when you're code is perfectly fine.
So if you're properly unloading everything, I see nothing wrong with using the End statement. It's just one of those things which we normally wouldn't need, sorta like the Call, Let, and GoTo statements.
Hello,
Sorry to intervene.
Using End is really a very bad habit ans could be dangerous (fatal) in certain circumstances (sub-classing, certain hooks, and so on...)
The best is to definitely get rid of this bad habit (so that we never run any risk).
Best regards to you all.
I rarely use it but it is not a bad habit if it is used correctly. The bad habit is using it instead of closing the objects created by your program. Technically the last line of code to execute in every program should be End. Ahead of which should be any code to release memory, close files, terminate objects and so forth.Quote:
Originally Posted by moa
If you use End and you have a fatal problem the problem is not with the end statement but with your other code. My advice would be that if you do not know how to realease the objects you have created then you should not be creating them. The usage of End or lack thereof is not the issue.
Consider this:
They still have old commands with new languages (to be backward compatible). There is an END statement in VB.Net.
It should NOT be used, because of *unpredictable* results.
VB.Net allows threads to start other threads. They can call other objects, and consume memory, and then properly destroy them.
If you stop the program using END, the OS no longer even *KNOWS* about those threads.
What happens next is *unpredictable*.
END is bad, and if you can find a place where it *HAS* to be used, then acknowledge it, awarding lots of points, if it can't be re-written,
i did all the suggessions and still my program is running.
i check for undestroyed object i ceated.
put the program terminations codes under form unload event etc. non of them workd.
its true that i use many 3d party ocx, dlls, and classes. so now i think probably the problem is with one of them. cant this be?Code:Shell_NotifyIcon NIM_DELETE, t
Dim frm As Form
For Each frm In Forms
If frm.Name <> Me.Name Then ' Unload this form LAST
Unload frm
Set frm = Nothing
End If
Next
End
This just works fine :D
shall i go for it :DCode:Private Sub Form_Unload(Cancel As Integer)
Shell_NotifyIcon NIM_DELETE, t
' Dim frm As Form
' For Each frm In Forms
' If frm.Name <> Me.Name Then ' Unload this form LAST
' Unload frm
' Set frm = Nothing
' End If
' Next
End
End Sub
I no a big dicsussion is going on regarding End :D
Interesting
Try this:
Also, with any variations you've tried, has there been any difference between running from the IDE, and fully compiled?Code:Private Sub Form_Unload(Cancel As Integer)
Shell_NotifyIcon NIM_DELETE, t
Dim frm As Form
For Each frm In Forms
If frm.Name <> Me.Name Then ' Unload this form LAST
Unload frm
Set frm = Nothing
End If
Next
If Not frm Is Nothing Then
Debug.Print "hey, it's not nothing!"
Set frm = Nothing
End If
End
End Sub
i put this code and removed the old code in the unload event, nothing is printed. but now i see the exe is terminated :confused:Quote:
Originally Posted by WizBang
really confusing.
i complied and check but putting a msgbox "hey, it's not nothing!"
noting displayed.
sorry sorry, Again exe remains with above code, it look like some time it does and some time it does not :confused:
i mean after performing some actions,
If it exits ok only if you haven't had it do anything, then one or more of those external dependencies you mentioned may be suspect.
If all fails, we could try a direct kick at the process, (which is like using brute force), terminating the process which has created the window you are in.
You need to declare three API functions and write one sub which I called KickMe()
If you put the above code in your Form which is the starting object of your application, it's process should be completely eliminated by calling KickMe. You could put this call into the Form_Unload(), or for testing just drop a CommandButton on your form and call it from the _Click() event.Code:Private Const PROCESS_ALL_ACCESS = &H1F0FFF
Private Declare Function OpenProcess Lib "kernel32" ( _
ByVal dwDesiredAccess As Long, ByVal bInheritHandle As Long, _
ByVal dwProcessId As Long _
) As Long
Private Declare Function TerminateProcess Lib "kernel32" ( _
ByVal hProcess As Long, ByVal uExitCode As Long _
) As Long
Private Declare Function GetWindowThreadProcessId Lib "user32" ( _
ByVal hwnd As Long, lpdwProcessId As Long _
) As Long
Private Sub KickMe()
Dim PID As Long
Dim Pro As Long
'get the process ID of this window
GetWindowThreadProcessId Me.hwnd, PID
'get a process handle for this
Pro = OpenProcess(PROCESS_ALL_ACCESS, 0&, PID)
'terminate this process
TerminateProcess Pro, 0&
End Sub
But note: If you run this code in the IDE, the complete IDE is terminated, because in the end the IDE was the creator of the Form when starting the program.
So put this in, SAVE your code and THEN test it.
Quote:
Originally Posted by WoF
hey wof, hmm, another simple solution. currently i am using another exe to terminate my app process and terminate itself. works charm. any way, i ll try this one also.
The "END" did not work for me,
this is what happens
click program tray icon to launch the Magnifer of my application, now if i click "exit program" menu item (which has set to "end") the program terminates and the magnifer window remains freezed on the screen and the process also running.
other solution , unload all the forums and unlaod the main form also did not work, even after that i put end.
This Magnifier you mention; does this mean you have a timer running continuously?
hmm, yah yah :)
but wizbang,
even if i open the 'about' window and close the main from form tray, that closes and process remian.
OK, here's what I'd try. I'd copy the entire project into a new folder. Then remove all forms except one, and try it. If it still stays running, I'd remove some controls and try again. At some point it should unload properly. Are there any .bas or .cls modules included in the project?
yah i have many .bas and 3rd party classes :(
ok, ill try all the options today i got !
The process termination code I advised before, was able to successfully terminate a testprogram I made, containing third party controls and a dummy class which makes a large object which is never released properly. Seems to work good so far.