Re: COM interface... but really only VB and ASP/VBscript

[Chris <cud -at- telecable -dot- es>]

This sounds like a perfectly viable situation.  For whatever reason, the 
company decides it only wants to support a subset of what the technology 
can do - probably a financial decision, but one that makes sense for the 
company.  Perhaps they don't want to hire the support staff - perhaps 
they just don't want to test C++, perhaps they don't have C++ customers 
out there.

On the other hand, my experience with COM suggests that aside from 
syntax there's very little differnce between COM in VB and COM in C++ - 
or at least the differences that matter are so specific to the 
languages/environments that you would have to modularize that stuff 
anyway.  I'm talking about things like how to load the proper data into 
your environment - as I recall in VB you just somehow attach to the 
server and VB figures out what you can access.  In C++ you import the 
table and VC++ generates the code you need to access the methods and 
properties.  These things are very specific to the environment, and I 
don't see a problem just documenting one now, and maybe the other later.

I think you can find a happy medium in this - Aside from specifics about 
how to get the methods into a specific IDE, things are pretty generic. 
You have methods and properties.  If you just document these without the 
specific syntax, a reasonable developer in C++ or VB will know what to 
do.  If you want to show sample code, you can modularize that via links 
- don't embed them in the method's discussion.  If you feel compelled to 
document specific syntax for each method, use something like conditional 
text (FrameMaker), or otherwise mark it for an automated replacement 
between C++ and VB.  (You should be able to do that in Word via 
VBScript, for example.)

Or have I missed something here?  (Very likely)

[SNIP...]