3.3 Debugging

Debugging

Debugging Automation code is something of a challenge. As we noted in Chapter 2, the VFP Debugger isn t much help. The Watch and Locals windows only show a property of an Automation object once that property has been accessed from VFP. So you can t drill into those objects to see what s going on and really examine them the way you can with native objects. We ve also sometimes found that putting COM objects (whether Automation objects or other COM objects) into the Watch window can be a good way to crash the Debugger.

So how do you debug Automation code? Carefully, and with a lot of advance planning.

Work in the Command Window

We do a lot of our testing and development in the Command Window. It s a lot easier to understand what s going on when we issue commands one at a time and examine the results. Once we re sure we know which methods to call and which properties to set to generate the desired documents, then we put them into code. We find this approach to be far more necessary (we daresay mandatory) with Automation code than with pure VFP code.

Collections and objects

Watch out for collections vs. individual objects. Since so much Automation code involves collections, it s really easy to call a method of a collection when you mean to call it for the object, or vice versa. For example, when you see something like the following, keep in mind that the object it references is an object, not a collection:

oPowerPoint.Presentations[1]

(This is actually another argument for using local variables. Setting oPresentation to refer to that presentation helps to avoid confusion.) A handy hint: generally, the collection object is plural (like Presentations), and the object itself is singular (like Presentation). It s pretty easy to get confused in the Help file looking for Presentation methods vs. Presentations methods, but knowing to look for the "s" (or not to) was a big breakthrough for us.

It works, but it doesn t

If your code runs, but the results are wrong, make sure you re manipulating the right objects. Recheck the appropriate sections in this book and in Help. Make sure you can perform the task (or at least a prototype of the task) interactively. We ll say it again you can t automate what you don t understand. Try recording a macro that performs what you re trying to automate, and then examine the resulting VBA code to see whether it sheds some light on the situation.

Parameter problems

If you re having problems with type mismatch errors in method calls, try changing the order of the parameters. Sometimes (though much less often than in older versions of Office), they re wrong in the docs. Use the Object Browser to be sure of the proper order. (See Chapter 2, "The Office Servers," for more on this.)

Similarly, if you re having trouble with an invalid number of parameters, you may need to add commas to allow for omitted defaults. Again, check in the Object Browser to see the correct list of parameters for a method.

Unhelpful error messages

When an error occurs on an Automation command, it falls into one of three broad categories: you asked VFP to do something it can t do, you asked the server to do something it can t do, or something went wrong in the communication between them.

In the first case (a VFP problem), you get a normal VFP error message and can handle it as you would any other. Things to check in that situation are matching parentheses, mismatched data types, and so forth.

In the second case, you see one of just a few error messages you get when an OLE error occurs. It s almost always either 1426 or 1429. Along with it, you get an error message of varying information content. Sometimes, it s truly informative. For example, if you ask for oWord.ActiveDocument.Name when there is no active document, the error message includes "This command is not available because no document is open." That s pretty good.

But other times, the messages are pretty sparse. For example, querying a non-existent property or misspelling a method yields simply "Unknown name." We think "No such member" would be a whole lot more helpful. Really helpful would be something like "This object does not have a member called Mane. " Then we d quickly notice that we d mistyped "Name" as "Mane" (again). But that seems to be asking for too much.

The real issue is that Visual FoxPro can t give you more information about the error than the application it s talking to gives it. That s because Visual FoxPro only knows what the server tells it. When one of these errors occurs, you need to look hard at the syntax of your command, compare it to the expected syntax, and try to figure out where you ve gone wrong.

The third group of errors reflects the difficulties of communicating between two applications. These may occur if the server is shut down unexpectedly (say, if the user closes the server from outside your application) or if there s a problem opening the server. See Chapter 14, "Handling Automation Errors," for ideas on how to handle these problems gracefully.

Use the Knowledge Base

While finding things in the Microsoft Knowledge Base can be difficult, there is a tremendous accumulation of information there. When you re stuck on a tricky problem, it s worth digging in and trying a number of search combinations. If you re having a particular problem, chances are someone else has had it before you.

Try combinations like "Automation" plus "FoxPro" plus the name of the application you re having trouble with. If that doesn t work, try taking FoxPro out of the mix maybe this is a problem in VBA, too. Search for the particular error code (not the VFP error number, but the OLE error code returned by the server), or use a phrase from the error description that comes back from the server.

Ask around

Still stuck? There are plenty of places to get on-line help with both VFP and the Office applications. Check out the list in Appendix A, "On-line User Communities." Be sure to provide enough information in your message to effectively describe your problem, but not so much detail as to make your message overwhelming. Often, the very process of trying to verify that your error occurs with the least number of simple steps will lead you to a solution, when in fact the error does not occur in the simplest case. Add complexity back in, one command at a time, and you can often isolate the source of your problem.

 

Copyright 2000 by Tamar E. Granor and Della Martin All Rights Reserved



Microsoft Office Automation with Visual FoxPro
Microsoft Office Automation with Visual FoxPro
ISBN: 0965509303
EAN: 2147483647
Year: 2000
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net