Yeah, that part was for Jonathan. It's his program, after all, in the final analysis—he's the one who has to make it work. I hope he'll try it, because (as you already know) the debugging features in the VBA editor are a lot better than writing a lot of of MsgBox calls to figure out what's going on.

Believe me, I was 'way behind you when I first started on VBA. I'd been doing traditional coding for a long time, and I knew Basic well enough; I just didn't understand how object-oriented programming was different, and it caused me no end of frustration at first. Writing my first simple object cleared up a lot of my confusion; it wasn't necessary for the task I was trying to write, strictly speaking, but it helped me understand what I hadn't before about the difference between a function and a "method".

I don't have anything against For statements—it's probably what I'd go to first, in this case—but rather than hard-code the last row ("For X = 1 To 104"), I'd be willing to take a lot of trouble to get the program to figure out for itself what the last row is. That's because the program is sure to be run many times between now and Whenever, and you don't want to have to change it repeatedly—and, likely as not, have to change it when you're already busy and can't spare the time, or (even worse) not realize it has to be changed, and then wonder why your data isn't right. So I'd tell the program to go looking for the last line, and use that in the loop.

As for the loop itself, I probably would do it pretty much the same way you did. Oh, I have a preference for changing the output row before the write instead of after, and I never name variables X any more (because of a mishap in another language entirely; but those are more programming style than The One Right Way to do something; any programmer will tell you there are lots and lots of ways to skin every cat you ever saw.