One of the best ways to figure out how to do it programmatically is to go into Excel, begin recording a macro, and then do the thing you want to do manually, and then stop recording your macro.
Rick,
I have to disagree with you - at least, up to a point. You are right that, in many cases, recording a macro can provide a good start in working out what code you write. But there several arguments against it. Tamar has often written about this (as have other developers); see for example her conference paper
Office Automation Tips Tricks and Traps.
I'll try to summarise the issues:
1. The code generated by the macro recorder often does a lot more than the basic task at hand. And that might include things that you don't want to do. The example Tamar gives is changing a cell to bold. The generated code will do that, but it will also include instructions to change all the other font settings (font name, font size, underline, italic, strike through, etc). If you are not careful, this could lead to unwanted side effects when converting to VFP.
2. In Excel, macros tend to work with selections rather than ranges. There are lots of reasons that it's usually better for your code to use ranges.
3. The way you perform a task when recording a macro is not always the best way to perform that task in code. Her example is formatting an entire column. In Excel, you might do that by formatting the first cell in the column, and then copying the format down to the rest of the column. But in your code, it would probably be less verbose and more efficient to format the entire column object at once.
I'm not saying you should never use the macro recorder. On the contrary, I use it quite a lot myself - but only to give me a hint to help me start writing my code. But you do need to use it with caution, and to take care when interpreting its output.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads