VBA Runs After Application.Quit

A

Andy

Can someone please explain why Application.Quit is ignored
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
 
G

GerardV

Op 16-4-2011 19:41, Andy schreef:
Can someone please explain why Application.Quit is ignored
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
Click to expand...

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
 
A

Andy

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
Click to expand...

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
 
J

Jim Cone

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".
 
G

GS

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.

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?
 
A

Andy

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".
Click to expand...

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
 
A

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.
Click to expand...

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?
Click to expand...

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
 
G

GS

After serious thinking Andy wrote :
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.
Click to expand...

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
 
J

Jim Cone

Re: "Still working on this - the last workbook for some reason is not closing"
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
 
A

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>
Click to expand...

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
 
G

GS

Andy laid this down on his screen :
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
Click to expand...

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
 
G

GS

Forgot to post this function...

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
 
A

Andy

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
Click to expand...

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
 
G

GS

Andy wrote :
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
Click to expand...

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.
 
B

bllittle

Andy, does your workbook have any MSForms controls embedded in a
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.
 
A

Andy

Andy, does your workbook have any MSForms controls embedded in a
worksheet?
Click to expand...

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.
Click to expand...

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
 
B

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!   :)
Click to expand...

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
 
A

Andy

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.
Click to expand...

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
Click to expand...

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
 
B

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.
Click to expand...

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

VBA Export to PDF 0
Self Closing MsgBox 6
Excel 2007 - VBA Password Input shows after Excel is closed 3
VBA-Table Word 2019 - Move a selected text, from a cell to the adjacent cell to its right, by pressing the ENTER key 0
Excel Application.Quit problem 0
delete modules 1
WORD VBA Search and switch to advanced ... 1
Application.Quit Does not Close the Application 6

Top