Technically, the same smart document can apply to both Word and Excel. In practice, if you want your smart-doc to actually DO something, chance are half your code will be hacked and kludged to work for both. For example:

• The XML model is different for the two applications.
• To get Smart Document controls to respond to the entire document in Word, you'll use the element <My schema namespace>#actionPertainsToEntireSchema.
  In Excel, you'll bind to http://schemas.microsoft.com/office/smartdocuments/2003#default.
  Needless to say, this is not documented anywhere.
• Assuming we've accepted the fact that an ActiveX control bound to one of these generic elements in entirely inaccessible from code (Here, about 80% of the way down. Running a search for “pertains“ should do it), we still can't use the same code for Word and Excel even for standard elements: XML elements in word are of type Microsoft.Office.Interop.Word.XMLNode. Excel's XML model is different, and uses element-mapping to cells or ranges. Even if we do get a node, to get the Smart Tag Action from it we'll use Microsoft.Office.Interop.Word.SmartTag, while Excel has Microsoft.Office.Interop.Excel.SmartTag. Similar? Very. Compatible? Not necessarily.

In short - if you gotta support both Word and Excel, I would suggest having two different Smart Document solutions. It would seem like the less elegant solution, but when you start seeing every function broken up into huge, distinct if/else blocks, you can tell that something's just not right.

No Comments