Tuesday, January 23, 2007 8:22 PM
Maybe you've written VBA macros for Office, or used COM interop to leverage Microsoft Office clients (Word, Excel, etc.). When I worked at MCI (WorldCom, Verizon, whatever it is now!), we had a system to watch a database for rows to be inserted in a given table, then generate form letters with Microsoft Word based on that data. When I first saw the application (obviously, I didn't write it!), I was amazed that such a thing could even be done. It was like a world of opportunity opened having access to Microsoft Office features as part of your code. Unfortunately, it was pretty fragile. Word would actually pop up, open a document template, perform replacements, then print it and close the document (without saving that document of course). Most of the time, the letters poured out, but it frequently went south. It was too much like remote control. Even using COM interop, user interaction or even random popups could mess things up. Looking back, I have to wonder if it wasn't done 100% properly, but it was a good example that Word could be automated.
VBA macros are another route to automating Word, but on a smaller scale. I've written a few macros to do simple tedious things, such as pasting unformatted text using a hotkey. VBA has been used for some interesting projects, but the requirement of using classic VB has always been a no-starter for me personally. Also, macro security is a topic that has made people shy away from it.
VSTO (Visual Studio Tools for Office) is the newest way to leverage Office in applications, and it's really cool. You write C# or VB.NET code, and the assembly can actually be embedded in or referenced from a document. This custom code can react to events, but it goes even further. You can write custom controls to embed within the Smart Pane (typically the Research/Clip Art/Styles/etc. browser on the right side). You can even embed controls within the document surface. Now you can query a database, invoke a Web service, or perform any other custom logic with full programmatic access to Office features. I'm most excited about Outlook extensibility personally, but I can see lots of business usability with the other apps too.
Now, Microsoft is re-branding the entire Office development experience as the Office Business Applications Platform. OBA's (as they call them) take advantage of Microsoft Office client tools for the user interface, and leverage the Office Server back-end tools such as SharePoint, Business Data Connector, Excel Services, etc. to aggregate, connect, present, process information while making it easier to add communication and collaboration features for the users. It's a good idea. Instead of rebuilding so much functionality for reporting, presentation, and workflow routing, you get a huge amount of code built for you. People are so used to working with their Office apps anyway. So much app development centers around trying to mimic or hook into Office functionality anyway. Why not truly merge them. Data can pop in place, advanced business rules can be applied, yet people can send these live documents around like they always have. They really rely on SharePoint for workflow processing and portal functionality, and InfoPath for certain forms functions and I don't know either of these technologies well enough yet.
I'd better start playing around with Office dev more. As people start to catch on, it's really going to explode. If you've watched people work at your company and wished you could remove the copy-and-paste steps and the errors introduced by incorrect file versions being passed around, you should definitely take a look.