Hi all,

Sometimes, application breaks at an execution point and this execution point
is the next statement, so how can I find the just previously executed
statement? This may sound obviating in a sequence execution case, but what
about in blocks of IF ...ELSEIF case?

Clara
--
thank you so much for your help

"clara" wrote in message
...
Sometimes, application breaks at an execution point and this execution
point
is the next statement, so how can I find the just previously executed
statement? This may sound obviating in a sequence execution case, but what
about in blocks of IF ...ELSEIF case?

Hi Clara,

There's no automatic way to figure this out that I'm aware of. You can
do one of two things. The simplest and most reliable would be to place a
break point before the whole block of code that you are interested in and
then step through it manually to determine which path the code takes.

The other option is to examine the values of all the relevant control
variables and expressions while still in break mode and use that to infer
which path the code took to get where it currently is. The problem with this
method is that it's quite possible for your code to change the state of
these variables and expressions such that it's no longer possible to
reliably determine the previous execution path.

--
Rob Bovey, Excel MVP
Application Professionals
http://www.appspro.com/

* Take your Excel development skills to the next level.
* Professional Excel Development
http://www.appspro.com/Books/Books.htm

There's no automatic way to figure this out that I'm aware of. You can
do one of two things. The simplest and most reliable would be to place a
break point before the whole block of code that you are interested in and
then step through it manually to determine which path the code takes.

Another technique that I like to use is to place Debug.Print statements at
the key points in the execution path having them print out (to the Immediate
window) location and and variable information. As an example....

Debug.Print "I'm in MySub; MyVariable = " & MyVariable

These Debug.Print statements can be anywhere in your code (event procedures,
functions, etc.) allowing you to run your code to the break point and then
simply read where you have been and what any key variables were along the
way.

I usually place the Debug.Print statements flush-left so that stand out
against my indented code making them easy to find when the debugging session
is over and I want to remove them.

Rick

Hi Rob,

i like your second method better because it is at least a semi-automatic way.
I read your Professional Excel Development book, in Chaper 16 VBA Debugging
on page 553, you wrote"Having a clear marker on the line of code that will be
executed next tends to be much more valuable than having a marker on the line
of code you just executed. The latter is easily determinded from the former,
but not necessarily vice versa"
Could you explain it again here?

Clara
--
thank you so much for your help


"Rob Bovey" wrote:

"clara" wrote in message
...
Sometimes, application breaks at an execution point and this execution
point
is the next statement, so how can I find the just previously executed
statement? This may sound obviating in a sequence execution case, but what
about in blocks of IF ...ELSEIF case?

Hi Clara,

There's no automatic way to figure this out that I'm aware of. You can
do one of two things. The simplest and most reliable would be to place a
break point before the whole block of code that you are interested in and
then step through it manually to determine which path the code takes.

The other option is to examine the values of all the relevant control
variables and expressions while still in break mode and use that to infer
which path the code took to get where it currently is. The problem with this
method is that it's quite possible for your code to change the state of
these variables and expressions such that it's no longer possible to
reliably determine the previous execution path.

--
Rob Bovey, Excel MVP
Application Professionals
http://www.appspro.com/

* Take your Excel development skills to the next level.
* Professional Excel Development
http://www.appspro.com/Books/Books.htm

"clara" wrote in message
...
i like your second method better because it is at least a semi-automatic
way.
I read your Professional Excel Development book, in Chaper 16 VBA
Debugging
on page 553, you wrote"Having a clear marker on the line of code that will
be
executed next tends to be much more valuable than having a marker on the
line
of code you just executed. The latter is easily determinded from the
former,
but not necessarily vice versa"
Could you explain it again here?

Hi Clara,

That statement was quite simply wrong and I have no idea what I was
thinking when I wrote it. I plan on removing it from the second edition of
PED which we are working on now and hope to have published sometime early
next year.

--
Rob Bovey, Excel MVP
Application Professionals
http://www.appspro.com/

* Take your Excel development skills to the next level.
* Professional Excel Development
http://www.appspro.com/Books/Books.htm

Thanks Rob
--
thank you so much for your help


"Rob Bovey" wrote:

"clara" wrote in message
...
i like your second method better because it is at least a semi-automatic
way.
I read your Professional Excel Development book, in Chaper 16 VBA
Debugging
on page 553, you wrote"Having a clear marker on the line of code that will
be
executed next tends to be much more valuable than having a marker on the
line
of code you just executed. The latter is easily determinded from the
former,
but not necessarily vice versa"
Could you explain it again here?

Hi Clara,

That statement was quite simply wrong and I have no idea what I was
thinking when I wrote it. I plan on removing it from the second edition of
PED which we are working on now and hope to have published sometime early
next year.

--
Rob Bovey, Excel MVP
Application Professionals
http://www.appspro.com/

* Take your Excel development skills to the next level.
* Professional Excel Development
http://www.appspro.com/Books/Books.htm