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

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

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

On Mon, 18 Apr 2011 11:31:58 +0200, GerardV
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

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".
--
Jim Cone
Portland, Oregon USA .
http://www.mediafire.com/PrimitiveSoftware .
(Bingo Card Variety, Excel workbook - in the free folder)

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?

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

On Tue, 19 Apr 2011 21:16:31 -0700, "Jim Cone"
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

On Wed, 20 Apr 2011 01:19:34 -0400, GS 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.


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

After serious thinking Andy wrote :
On Wed, 20 Apr 2011 01:19:34 -0400, GS 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

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

"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"
wrote in message
...
On Tue, 19 Apr 2011 21:16:31 -0700, "Jim Cone"
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

On Thu, 21 Apr 2011 21:35:21 -0400, GS wrote:

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

Andy laid this down on his screen :
On Thu, 21 Apr 2011 21:35:21 -0400, GS wrote:

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

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

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

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

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

On Sun, 24 Apr 2011 12:43:09 -0400, GS wrote:

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

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

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

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.

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

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.

On Apr 24, 10:01*am, Andy wrote:

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.

On Mon, 25 Apr 2011 09:38:01 -0700 (PDT), bllittle
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

On Apr 25, 8:53*pm, Andy wrote:
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

On Tue, 26 Apr 2011 08:46:20 -0700 (PDT), bllittle
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

On Apr 26, 6:09*pm, Andy wrote:
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.