I’m a big fan of using the proper application for the task, e.g. Word for documents, Outlook for contact management, Access for databases. Because of that, I really like automating other applications. Most of my automation is from Excel, though there’s a bit from Access too.
When you automate another application, you expose its object model so you can access its objects and their properties and methods. That means you have to learn the syntax if you’re going to automate it successfully. Sometimes the syntax is easy and intuitive. Other times, not so much.
Because I was raised on Excel’s object model, I think it’s the best. Even when I try to be objective about it, I still think it’s better than some others that I’ve used. Below are some of my complaints about object models of other applications.
Selection – I know Excel has a Selection object, and don’t get me wrong, it’s useful. But it seems that everything you want to do in Word requires the use of the Selection object. When I automate Word, I try to avoid using Selection, but sometimes it’s just impossible. Even when it’s possible I end up with the some convoluted Range object.
When I think about Word’s objects, I think about a Documents collection, a Sections collection, a Paragraphs collection, a Words collection, and a Characters collection. It seems you could do just about whatever you want with those, particularly if each object has its Parent object set up correctly.
Documents(1).Paragraphs(2).Sentence(3).Text = “Your text here”
That seems intuitive to me.
DoCmd – I complain about this one every chance I get. I like to tell Access guys that their object model only has two objects; the Recordset object and the DoCmd object. On its face, DoCmd seems to be a stroke of genius. Almost anything that you can do from the UI you can do using DoCmd. But the object model isn’t supposed to simply mimic the menu structure. This line:
at least if it was up to me.
FileOpen, FileSave – I alluded to this monstrosity in a previous post. There is a Projects collection and it even has an Add method to create new Projects. Why, then, didn’t that make an Open method to open existing ones? Why not throw in a Save method? Instead I have to use Application.FileOpen.
GetNameSpace – according to help, the only valid argument to this method is “MAPI”. Here’s an idea: don’t require an argument. Maybe it’s for “future expansion”, but it’s been the same since at least OL98. Also, in 2003, Outlook went through it’s most extensive overhaul ever. If they wanted to expand, that was probably the time.
I love complaining. If you do too, leave a comment with your object model complaint.