VBA Runs After Application.Quit
Andy
here and VBA goes on working? This is on Excel 97. My
code is similar to this:
Sub My_subrtn()
Application.DisplayAlerts = False
Dim x As Integer
x = 3
If x > 2 Then
Application.Quit
End If
MsgBox "VBA is still running"
MsgBox "VBA is still running"
MsgBox "VBA is still running"
End Sub
Here, Application.Quit is ignored(?) and all the MsgBoxes are
executed.
I googled this and found that a DoEvents after the
Application.Quit statement solves the problem. Does anyone
know why?
I ask because I always thought that each statement in the
program must be executed before the next statement enters
the program. The above behavior throws that out the window.
In this case for example, do I need a DoEvents statement
after x = 3 in order to make sure the If statement doesn't
execute first? In other words what is it that makes
Application.Quit different?
Thank you for your time.
Andy
GerardV
Hi Andy,
Not realy shore why the subroutine is continued, but i think it's
because excel wait for the subroutine to be finished before it closes.
maybe you shoot ad Exit Sub after the Application.Quit ....
Sub My_subrtn()
Application.DisplayAlerts = False
Dim x As Integer
x = 3
If x > 2 Then
Application.Quit
Exit Sub
End If
MsgBox "VBA is still running"
MsgBox "VBA is still running"
MsgBox "VBA is still running"
End Sub
Gerard
Andy
wrote:
>
>Hi Andy,
>
>Not realy shore why the subroutine is continued, but i think it's
>because excel wait for the subroutine to be finished before it closes.
>
>maybe you shoot ad Exit Sub after the Application.Quit ....
>
>Sub My_subrtn()
> Application.DisplayAlerts = False
> Dim x As Integer
> x = 3
> If x > 2 Then
> Application.Quit
> Exit Sub
> End If
> MsgBox "VBA is still running"
> MsgBox "VBA is still running"
> MsgBox "VBA is still running"
>End Sub
>
>
>Gerard
Thanks for the reply Gerard. Even if you Exit Sub after the
Application.Quit, VBA is still running. Here is your subroutine with
a minor modification - This is on Excel 2000:
Sub My_subrtn()
Application.DisplayAlerts = False
Dim x As Integer
x = 3
If x > 2 Then
Call JustQuit
End If
MsgBox "VBA is still running"
MsgBox "VBA is still running"
MsgBox "VBA is still running"
End Sub
Sub JustQuit()
Application.Quit
End Sub
Again, thanks for the reply.
Andy
Jim Cone
Something as simple as...
Workbooks.Close
Application.Quit
If you are automating Excel, then you have to call quit on the object reference not "Application".
--
Jim Cone
Portland, Oregon USA .
http://www.mediafire.com/PrimitiveSoftware .
(Bingo Card Variety, Excel workbook - in the free folder)
GS
need to work with that! In all probability, Excel has a 'Terminate'
event that runs before shutdown occurs.
I'm not sure why you have executable code after the Application.Quit
statement but that's rather unusual. This is a normal statement for a
shutdown routine that also handles menus, toolbar, and UI settings
cleanup as well as saving of any open workbooks, BUT this is always the
last executable line in the shutdown routine.
Also, the shutdown routine might begin with 'On Error Resume Next'
since at this point it's too late to mitigate any errors that might
occur.
Are you actually using this statement in a project OR just messing
around with it for curiosity?
--
Garry
Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Andy
<james....@comcast.netXxx> wrote:
>Try closing all workbooks before calling quit.
>Something as simple as...
>Workbooks.Close
>Application.Quit
>
>If you are automating Excel, then you have to call quit on the object reference not "Application".
Good tip - thank you. To make it work I ended up closing the
workbooks one by one - something like:
ActiveWorkbook.Close Savechanges:=False
Workbooks("Name_01.xls").Close Savechanges:=False
(Still working on this - the last workbook for some reason is not
closing)
As an aside, I always thought that "Application.Quit" will close all
workbooks no questions asked.
Again, Thank you.
Andy
Andy
>The behavior of the Application.Quit statement is what it is, and so we
>need to work with that! In all probability, Excel has a 'Terminate'
>event that runs before shutdown occurs.
>
>I'm not sure why you have executable code after the Application.Quit
>statement but that's rather unusual. This is a normal statement for a
>shutdown routine that also handles menus, toolbar, and UI settings
>cleanup as well as saving of any open workbooks, BUT this is always the
>last executable line in the shutdown routine.
In this case the need to shut down is the result of an error in the
spreadsheet. If it does not shutdown then it mails itself to a
number of users who are now receiving the wrong information.
>
>Also, the shutdown routine might begin with 'On Error Resume Next'
>since at this point it's too late to mitigate any errors that might
>occur.
>
>Are you actually using this statement in a project OR just messing
>around with it for curiosity?
I did not think about 'On Error Resume Next' - I will give it a shot.
And no, this is not a curiosity item - I was very surprised to
discover that 'Application.Quit' is to some extend ignored by VBA
and Excel. I understand that it depends on the Operating System and I
am not clear yet on how to deal with this.
Thank you for the comments.
Andy
GS
> On Wed, 20 Apr 2011 01:19:34 -0400, GS <g...@somewhere.net> wrote:
>
>> The behavior of the Application.Quit statement is what it is, and so we
>> need to work with that! In all probability, Excel has a 'Terminate'
>> event that runs before shutdown occurs.
>>
>> I'm not sure why you have executable code after the Application.Quit
>> statement but that's rather unusual. This is a normal statement for a
>> shutdown routine that also handles menus, toolbar, and UI settings
>> cleanup as well as saving of any open workbooks, BUT this is always the
>> last executable line in the shutdown routine.
>
> In this case the need to shut down is the result of an error in the
> spreadsheet. If it does not shutdown then it mails itself to a
> number of users who are now receiving the wrong information.
Could you not recode the procedure that does this to abort if the error
exists, giving the user an instruction as to how to correct the error
maybe. I'm thinking it might be easier to exit a sub/function than code
for all the nuances surrounding a shutdown.<g>
>
>>
>> Also, the shutdown routine might begin with 'On Error Resume Next'
>> since at this point it's too late to mitigate any errors that might
>> occur.
>>
>> Are you actually using this statement in a project OR just messing
>> around with it for curiosity?
>
> I did not think about 'On Error Resume Next' - I will give it a shot.
>
> And no, this is not a curiosity item - I was very surprised to
> discover that 'Application.Quit' is to some extend ignored by VBA
> and Excel. I understand that it depends on the Operating System and I
> am not clear yet on how to deal with this.
>
> Thank you for the comments.
>
> Andy
--
Jim Cone
Corrupted workbooks are a problem and what they will do to workbook code is unpredictable.
I believe having multiple versions of Excel on your machine can help identify problems.
Sometimes that smoothly running piece of code has difficulties in another version.
(even if the "other" version will not be used to run the finished program, it pays to check)
--
Jim Cone
Portland, Oregon USA .
http://www.mediafire.com/PrimitiveSoftware .
(Extras for Excel add-in: convenience built-in)
"Andy" <Sorry@No_Address.com>
wrote in message
news:goj1r698d3lb4snq6...@4ax.com...
Andy
>
>Could you not recode the procedure that does this to abort if the error
>exists, giving the user an instruction as to how to correct the error
>maybe. I'm thinking it might be easier to exit a sub/function than code
>for all the nuances surrounding a shutdown.<g>
I ended up using
ActiveWorkbook.Close Savechanges:=False
to close the offending workbook and this allowed the remaining
workbooks to resume and shutdown gracefully.
My take at this point is that Application.Quit works fine in a single
workbook and if multiple workbooks are present then something like
ActiveWorkbook.Close Savechanges:=False
Workbooks("Name_01.xls").Close Savechanges:=False
is the way to go.
Thank you all for the comments.
Andy
GS
Actually, I iterate the workbooks collection to close all open
workbooks (allowing option to save) before executing the
"Application.Quit" statement. Since my apps usually run in their own
automated instance of Excel, all shutdown cleanup mimics what Excel
would normally do if you shut it down with multiple workbooks open.
Here's an example:
Sub ShutdownApp()
On Error Resume Next
If lCountVisibleWorkbooks() > 0 Then
Dim Wkb As Workbook, vAns As Variant
Dim bUserCancel As Boolean, bSave As Boolean
With Application
.EnableEvents = False: .DisplayAlerts = False
End With
For Each Wkb In Application.Workbooks
If Wkb.Windows(1).Visible Then
If Not Wkb.Saved Then
vAns = MsgBox("Do you want to save changes to " _
& Wkb.Name & "?", _
vbYesNoCancel + vbExclamation, gsAPP_NAME)
Select Case vAns
Case Is = vbNo: Wkb.Close False
Case Is = vbYes: Wkb.Close True
Case Else: bUserCancel = True: GoTo CancelExit
End Select
Else
Wkb.Close False
End If
End If
Next
End If
CancelExit:
With Application
.EnableEvents = True: .DisplayAlerts = True
End With
If bUserCancel Then Exit Sub
'If we got here then we're ready to quit
gbShutdownInProgress = True
Application.Visible = False '//hide any cleanup/restore activity
If Application.Version >= 12 Then _
Workbooks("ui12su.xlam").Close Else ResetExcelUI
HandleEvents("Stop")
Call ResetCommandBars: ResetBuiltInBars: RestoreExcelSettings
Application.Quit
End Sub
GS
Public Function lCountVisibleWorkbooks() As Long
Dim Wkb As Workbook
For Each Wkb In Application.Workbooks
If Wkb.Windows(1).Visible Then _
lCountVisibleWorkbooks = lCountVisibleWorkbooks + 1
Next
End Function
Andy
Garry, thank you - this I need to try.
But let me ask you about your use of "On Error Resume Next" at
the top of the subroutine - Why are you using it in this particular
subroutine?
I ask because up until recently I was under the impression that
the use of "On Error Resume Next" is limited to specific lines
of code and then cancelled with "On Error GoTo 0" - now I get
the impression that if you have a specific goal in mind, then...
it is ok?
I am just trying to understand this. Thanks.
Andy
GS
> Garry, thank you - this I need to try.
>
> But let me ask you about your use of "On Error Resume Next" at
> the top of the subroutine - Why are you using it in this particular
> subroutine?
>
> I ask because up until recently I was under the impression that
> the use of "On Error Resume Next" is limited to specific lines
> of code and then cancelled with "On Error GoTo 0" - now I get
> the impression that if you have a specific goal in mind, then...
> it is ok?
>
> I am just trying to understand this. Thanks.
>
> Andy
Hi Andy,
As I stated previously, this is a shutdown routine and so at this point
it's too late to mitigate any errors that may arise. While it's not
likely that any errors would arise, it's more of a precaution so
shutdown continues unconditionally. If you study the code you'll see
there's a lot of 'cleanup' going on and so we don't want any errors to
interupt the process.
bllittle
worksheet? I've been having the same issue (VBA continuing after a
workbook is closed as I can see a "ghost" of it if Excel remains
running and I open the VBE). In other other forums I've read that
these controls can be an issue with how they are registered. So far,
I've not found a way to get this particular workbook to "close
gracefully" but will try your approach.
Andy
<wunde...@gmail.com> wrote:
>
>Andy, does your workbook have any MSForms controls embedded in a
>worksheet?
No, no controls here. A task scheduling program fires up the first
workbook and from then on, Excel VBA takes over.
>
>I've been having the same issue (VBA continuing after a
>workbook is closed as I can see a "ghost" of it if Excel remains
>running and I open the VBE). In other other forums I've read that
>these controls can be an issue with how they are registered. So far,
>I've not found a way to get this particular workbook to "close
>gracefully" but will try your approach.
>
Well, credit belongs to Jim and Garry who suggested this earlier
in the thread. One thing to remember here is don't close the
workbook with the VBA code before you are done! :)
Andy
bllittle
> No, no controls here. A task scheduling program fires up the first
> workbook and from then on, Excel VBA takes over.
> Well, credit belongs to Jim and Garry who suggested this earlier
> in the thread. One thing to remember here is don't close the
> workbook with the VBA code before you are done! :)
Well darn. I'm still having issues with the VBA continuing, even after
trying the approaches supplied by Jim and Garry. Unfortunately, if
I've worked on it twice (or more) times, there are multiple instances
showing up in the VBAProjects pane and the more serious issue at that
point is that even though I close completely out of Excel our XP
operating system still seems to thing Excel is working on something
and has issues with shutting down the computer. What I'm finding odd
about that is it doesn't seem to give XP a problem if there is one
"ghost" still running, but once there is more than one, XP has a
problem.
Anyone have any suggestions?
Bruce
Andy
<wunde...@gmail.com> wrote:
>
>Well darn. I'm still having issues with the VBA continuing, even after
>trying the approaches supplied by Jim and Garry. Unfortunately, if
>I've worked on it twice (or more) times, there are multiple instances
>showing up in the VBAProjects pane and the more serious issue at that
>point is that even though I close completely out of Excel our XP
>operating system still seems to thing Excel is working on something
>and has issues with shutting down the computer.
It sounds like you are creating instances of Excel and you are
not making them visible - use,
objExcel.Visible = true
or something simlar right after you create an instance of Excel.
(This is the only thing I can think of to explain this).
> What I'm finding odd
>about that is it doesn't seem to give XP a problem if there is one
>"ghost" still running, but once there is more than one, XP has a
>problem.
>
>Anyone have any suggestions?
>Bruce
Delete all instances of Excel before you start. Use the Windows
Task manager to do so. (Again, I am assuming you are creating
these instances of Excel without making them visible).
Good luck.
Andy
bllittle
> Delete all instances of Excel before you start. Use the Windows
> Task manager to do so. (Again, I am assuming you are creating
> these instances of Excel without making them visible).
>
> Good luck.
thanks Andy! Turned out to be the ol' memory leak issue with using an
open workbook as a data source for a DAO object. I had been working
with some open data for testing and thought I'd made sure I'd changed
all those references in the "finished" product, but I'd missed one.
Works killer now, though! I got a charge out of the client saying
"This is fun!" when he was "driving" while I was demo'ing it for him,
since he was used to dry, static statistics and metrics displays.