I have a procedure that will not respond when I try to step through or run to
cursor. However, some procedures within the same module will respond to
debugging. I know that you cannot step through worksheet change events, etc,
but these procedures are in a normal module. Are there procedures you cannot
step through?

You CAN step through worksheet change events or any code. It's not clear why
you're having a problem, but perhaps you can put a breakpoint in the code to
force the single-step when it gets to that breakpoint line -- click on the
line of code, then press F9, then run the macro the usual way. When it gets
to the breakpoint line you'll be in step mode.
Bob Umlas
Excel MVP

"Emily Edgington" <(E-Mail Removed)> wrote in
message news:FD7D3C1A-D9E9-485D-8A2C-(E-Mail Removed)...
>I have a procedure that will not respond when I try to step through or run
>to
> cursor. However, some procedures within the same module will respond to
> debugging. I know that you cannot step through worksheet change events,
> etc,
> but these procedures are in a normal module. Are there procedures you
> cannot
> step through?

I found that if I remove the variable declaration in the Sub line, I can step
through. So I changed:

Sub ChangeSource(Optional intFileID As Integer)

to

Sub ChangeSource()

and I can step through or run to cursor to my heart's content. I guess that
is the reason I thought I couldn't step through worksheet change events - I
always have them set up with variable declarations in the Sub line (for all I
know, that's the only way).

Is this normal (that you can't step through with variables in the Sub line),
or a weirdness in my Excel (2000 on WinNT)?



"Bob Umlas" wrote:

> You CAN step through worksheet change events or any code. It's not clear why
> you're having a problem, but perhaps you can put a breakpoint in the code to
> force the single-step when it gets to that breakpoint line -- click on the
> line of code, then press F9, then run the macro the usual way. When it gets
> to the breakpoint line you'll be in step mode.
> Bob Umlas
> Excel MVP
>
> "Emily Edgington" <(E-Mail Removed)> wrote in
> message news:FD7D3C1A-D9E9-485D-8A2C-(E-Mail Removed)...
> >I have a procedure that will not respond when I try to step through or run
> >to
> > cursor. However, some procedures within the same module will respond to
> > debugging. I know that you cannot step through worksheet change events,
> > etc,
> > but these procedures are in a normal module. Are there procedures you
> > cannot
> > step through?
>

If you post your sub code, the group may give you better feedback on why
that declaration might have caused the original problem.

> I always have them set up with variable declarations in the Sub line (for
> all I
> know, that's the only way).

As someone who's never had the formal training to know better, I do the
opposite- I never set them up with variable declarations in the sub line,
with the infrequent exception of functions or subs where I absoloutely need
to pass data directly. I probably don't use it as often as I should (and
perhaps not correctly when I do), but I definitely wouldn't throw them in
unless you were intentionally going to pass a variable to that sub from a
calling procedure.

I look forward to reading some of the more expert replies on the subject.

HTH,
Keith

Hi Emily,

'---------------
Is this normal (that you can't step through with variables in the Sub line),
or a weirdness in my Excel (2000 on WinNT)?
'---------------

As your macro has an argument (intFileID), you need to
call it from another procedure.


To step though your macro, try something like:

'=============>>
Public Sub Tester()
Call ChangeSource(intFileID:=5) '<<=== CHANGE
End Sub
'<<=============


---
Regards,
Norman

When I said "I always have them set up with variable declarations", I was
speaking specifically of Worksheet Change Events. And the reason is because
I got the basic code from VBA Help files or some posting in the forum, etc.
and never felt comfortable making a change to it. For anything I wrote
myself (*cough*...or pasted together myself, if you will), I never use
variable declarations in the Sub line.

However, your suggestion is noted - I will try to remember to post the code
if it seems necessary or helpful.

"Keith R" wrote:

> If you post your sub code, the group may give you better feedback on why
> that declaration might have caused the original problem.
>
> > I always have them set up with variable declarations in the Sub line (for
> > all I
> > know, that's the only way).
>
> As someone who's never had the formal training to know better, I do the
> opposite- I never set them up with variable declarations in the sub line,
> with the infrequent exception of functions or subs where I absoloutely need
> to pass data directly. I probably don't use it as often as I should (and
> perhaps not correctly when I do), but I definitely wouldn't throw them in
> unless you were intentionally going to pass a variable to that sub from a
> calling procedure.
>
> I look forward to reading some of the more expert replies on the subject.
>
> HTH,
> Keith
>
>
>