Well, start at the beginning, though I've little doubt you've seen the first
step: You have to get to the Visual Basic Editor, where this code is typed
in.
You get there from your spreadsheet by selecting Tools, Macros, Visual Basic
Editor. Your actual code can be in a number of places there, but actually
I'm
sure you must already know about this part because after all how else could
you
have captured the code and copied it to us?

So now you're looking at your code and you want to know what's going wrong
with
it. I expect you inherited this code from someone else, rather than having
written it yourself, but you can still figure out what's going on if you can
watch the program run, step by step, seeing inside the program so to speak
so you
can tell what the statement it's about to execute and what is the value of
each
variable at any given time. And so you can: Use your arrow keys to bring
the
text cursor down until it's somewhere on the first line, the one that says
"Function EveryNth(etc)". With your text-insertion bar somewhere on that
line,
hit <F9.

Immediately that whole line is highlighted (probably in the shade of dark red
that I think of as burgandy), and a bugandy dot appears in the margin
immediately
to the left. In the language of VBA you have just set a "breakpoint" in your
program: When the program starts executing and gets to that point, it'll
stop
and invite you to look over the program, investigate current values, type
immediate commands for execution, even change some of the statements, and
then
tell it to resume execution. It's pretty powerful stuff.

You can set breakpoints on pretty much any executable statement in your
program,
either by using <F9 or by just clicking with your mouse in the left margin
next
to your line. If you hit <F9 or click again on the same line, the
breakpoint
will go away.

Now watch what happens when you execute the program. By the way, how DO you
execute the program? I mean, do you go to Tools, Macros and pick a macro
from
the list to execute? Do you hit a button? Or is it, in this case, a
worksheet
function? If the latter, the way I always get it to execute (there may be
others) is just go back to the spreadsheet, to one of the cells that uses
that
function; there hit <F2 to start editing the formula in that cell, and then
hit
<Enter without changing anything.

Immediately, as I recall, the view will switch from the spreadsheet to the
VBE,
with the breakpointed line now highlighted in yellow, indicating that this
statement will be next to execute when you allow it. Since you put the
breakpoint on the Sub line, it hasn't done a blessed thing yet. That means
you're looking at in before it's done anything wrong, but that in turn means
you
haven't seen anything useful yet. Here's what you do: Hit <F8.

<F8 allows the program to execute exactly one command or statement, in this
case
the Function "command" itself. That doesn't do anything very interesting,
but if
you hit <F8 while you're looking at the VBE you'll see the yellow line jump
to
the next command, which is not, as you might, expect the next line ("Dim i As
Long") but ... well, actually, I'm not sure whether it'll be the ReDim or
the For
statement. At any rate it doesn't consider Dim to be an executable
statement so
it doesn't show you anything for those, just leaps over them - in fact if
you try
to set a breakpoint on a Dim statement, nothing happens because breakpoints
aren't allowed there.

At any rate, now the yellow marker has advanced one, and something
interesting
has happened. Hover your mouse cursor over any variable name in your code:
Num,
Nth, i, whatever. What you should see -- and if you don't, something's
wrong --
is a pop-up message saying, for example, "Num = 30". Most of the other
variables
will say simply "i = Empty", because you haven't assigned them any values
yet --
or come to think of it maybe they'll be set to 0, because of the Dim
statement.
But Num and Nth you'll be able to see once you've come out of the
introductory
Function statement itself.

Each time you hit <F8 it'll advance another step and you can see the
results.
You can advance one step at a time through the entire execution, if you like,
which will give you a clear picture of everything it's doing. But if that
get's
boring and you want to jump ahead, you can do either of two things:

1) Hit <F5; this just runs along and finished the execution without you.
But if
you still need to see what it's doing later -- just not right in this part
of the
program -- you can
2) Set another breakpoint, with the mouse or using <F9, and THEN hit <F5;
the
program will run along without you, just as before, but as soon as it gets to
this new breakpoint it'll stop and give you a chance to catch up again.

There are other and fancier things your can do. Look through the Debug menu
for
some of them, and in your Help file(s). But one thing for sure you'll need
to do
in this case, because you have arrays: You can't hover your mouse over x
and y
to get their value because they don't have "a value", they have more like 30,
being arrays. To see what's going on inside them you have to add them to a
"watch" window.

To do that, either bring down the Debug menu or right-click on the variable,
and
in either resulting drop-down menu select Add Watch. A little window will
pop up
allowing you to set some options; for now, just make sure the "Expression" is
equal to the variable you want to inspect and hit OK or <Enter. In the
Watch
window -- it should be just below your code window -- an entry for that
variable
shows up. If it's a scalar variable you can see its present value to the
right.
If it's an object or an array, you have to click on the + symbol to expand it
into its component parts. Either way you get a complete picture of what's
happening in this variable or object.

The Watch window in no way interferes with your ability to continue
executing the
program step by step or many at a time. These are the "tools" I had in
mind; you
can see what your program is doing, and if you know what it SHOULD be doing
then
you should be able to see at what point it goes wrong, and figure out why.

There's more, of course, but this is most of what I need for most debugging.

--- "Floyd" wrote:
Thank You Bob, Please, help me in learning the new tools so that I
can solve my problem.

--- "Bob Bridges" wrote:
....But if you want to keep on using the one you have, I think you'll have
to tell us what's "not working" about it. Is it bombing in the middle with
an error (and if so what error)? pretending to work but giving incorrect
results (and if so what results)?

Better yet, have you tried walking through its execution one step at a time,
using <F8 and the other debug tools? If you've never tried them before,
they're well worth learning; a little familiarity with them might well have
saved you these days of asking on the forum. If you're not sure how they
work, let us know and someone (me! pick me!) will help you get started.