Dynamically turn on debug

[Bill]

I have a client's DB wherein there's some
peculiarity in the data that the class module
apparently isn't checking for. I'd like to
turn debug on at the point of discovery and
step through the code as though there had
been a breakpoint at that location. Can this
be done?
Bill

 

[John W. Vinson]

I have a client's DB wherein there's some
peculiarity in the data that the class module
apparently isn't checking for. I'd like to
turn debug on at the point of discovery and
step through the code as though there had
been a breakpoint at that location. Can this
be done?
Bill

Could you clarify what you mean by "at the point of diescovery"?

 

[Bill]

If Me.Lastname = "Smith" then _
turn on breakpoint at next statement now

 

[Bill]

No replies means that it can't be done?
Thanks,
Bill

If Me.Lastname = "Smith" then _
turn on breakpoint at next statement now

 

[John W. Vinson]

No replies means that it can't be done?

Sorry. I've been fighting the flu. It's not an instant out of the box answer;
I'm not sure how it can be done right off hand.

Do note that we're all unpaid volunteers here. Nobody's getting paid to answer
your questions, and there are no guarantees of instant responses.

I'll try to come up with something and will mention it to other volunteers.

 

[msacc97 via AccessMonster.com]

If Me.Lastname = "Smith" then Stop

Using the Stop statement is similar to setting a breakpoint in the code.

If Me.Lastname = "Smith" then _
turn on breakpoint at next statement now
[quoted text clipped - 6 lines]

Could you clarify what you mean by "at the point of diescovery"?

 

[Bill]

Hi John,

Sorry if I sounded like I was complaining for lack of
response. I'm well aware of the volunteer nature of
all the MVP's and I'm always grateful for their
dedication to helping those with questions.

You take care of yourself, my problem isn't that
important.

Thanks,
Bill

 

[John W. Vinson]

Hi John,

Sorry if I sounded like I was complaining for lack of
response. I'm well aware of the volunteer nature of
all the MVP's and I'm always grateful for their
dedication to helping those with questions.

You take care of yourself, my problem isn't that
important.

Thanks, and sorry if I was sounding surly (I feel a bit surly...)

It looks like msacc97's answer is on track: use a STOP in the code.

 

[Bill]

That did the trick...........
Thanks much,
Bill
(PS) John, take care of yourself.

If Me.Lastname = "Smith" then Stop

Using the Stop statement is similar to setting a breakpoint in the code.

If Me.Lastname = "Smith" then _
turn on breakpoint at next statement now

I have a client's DB wherein there's some
peculiarity in the data that the class module

[quoted text clipped - 6 lines]

Could you clarify what you mean by "at the point of diescovery"?

 

[msacc97 via AccessMonster.com]

Good luck, Bill

That did the trick...........
Thanks much,
Bill
(PS) John, take care of yourself.

If Me.Lastname = "Smith" then Stop

[quoted text clipped - 8 lines]

 

[Banana]

Good luck, Bill

That did the trick...........
Thanks much,
Bill
(PS) John, take care of yourself.

If Me.Lastname = "Smith" then Stop

[quoted text clipped - 8 lines]

Could you clarify what you mean by "at the point of diescovery"?

Why not use a Debug.Assert?

Private Sub demo()

Dim i As Integer

i = 10

Debug.Assert i = 5 '<== will enter break mode

End Sub



Alternatively, use a watch and break on condition when true:

Debug -> Add Watch

Select "Break when condition is true" and enter for expression:

i <> 0 Or i = 5


As a matter of preferences, I don't like using Stop as it's quite
static; suppose I forgot about it one day and it got shipped out in a
production version? That would be quite embarrassing.

 

[Jack Leach]

http://www.cpearson.com/excel/Debug.htm

See here under Debug.Assert section. Will work in Access as well as Excel
(or Word, etc... this is native to VBA not the host application)

--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)

No replies means that it can't be done?
Thanks,
Bill

 

[Bill]

I'm not sure how it is that I missed Debug.Assert when
I searched for an answer prior to my original post. With
me, you would have a better than even chance of winning
if you bet I'd ship a production before removing the "Stop
Method"...............

Bill

That did the trick...........
Thanks much,
Bill
(PS) John, take care of yourself.

If Me.Lastname = "Smith" then Stop

[quoted text clipped - 8 lines]
Could you clarify what you mean by "at the point of diescovery"?

Why not use a Debug.Assert?

Private Sub demo()

Dim i As Integer

i = 10

Debug.Assert i = 5 '<== will enter break mode

End Sub



Alternatively, use a watch and break on condition when true:

Debug -> Add Watch

Select "Break when condition is true" and enter for expression:

i <> 0 Or i = 5


As a matter of preferences, I don't like using Stop as it's quite static;
suppose I forgot about it one day and it got shipped out in a production
version? That would be quite embarrassing.

 

[Banana]

I'm not sure how it is that I missed Debug.Assert when
I searched for an answer prior to my original post. With
me, you would have a better than even chance of winning
if you bet I'd ship a production before removing the "Stop
Method"...............

Bill

LOL.

I've actually seen production application where there were a bunch of
Debug.Print left behind. Not as nasty as a Stop or even Debug.Assert
which could introduce unwanted break, especially if the user isn't a
developer, but it does clutter up the immediate windows and add overhead
that isn't really needed.

There's also an alternative that isn't as common: compiler directives:

#Const Debug = 1 'We want the debug code to run.

Private Sub DoIt()

'Some code here...

#If Debug Then

Debug.Assert i = 5

#End If

'more code...

End Sub


All statements with leading # is actually an instruction to the
compiler, essentially telling it to only compile the statement
"Debug.Assert..." statement into the final output (which user will then
run) if and only if the Debug flag is set. (Can be named whatever, and
can be whatever values you like but I use it to illustrate).

Thus you get to keep all your debugging code intact and just set the
Debug to 0 when you're ready to ship. Sure beats chasing down every
stray Debug and Stops.

 

[David W. Fenton]

I'm not sure how it is that I missed Debug.Assert when
I searched for an answer prior to my original post.

It was introduced into Access only with A2000, and for many of us,
our programming habits were already developed. Only in the last year
or two have I started using the Access Replace() and Round()
functions (though I still often avoid the latter because it uses
banker's rounding, which is simply wrong half the time, even if it's
more accurate over large bodies of calculations). Tony Toews
recently posted about discovering InStrRev(). I didn't know about
it, either, having been depending on my own ReverseString() function
for many years.

BTW, I actually replied to point out a useful Luke Chung article on
error handling:

http://msdn.microsoft.com/en-us/library/ee358847.aspx

The article says it's specific to A2007, but I think there's almost
nothing at all in it that hasn't been applicable for nearly a
decade (i.e., since the release of A2000).