On 8/4/2011 12:26, Orchid XP v8 wrote:
> Now, aside from that matter, the thing which really puzzles me is this: If
> something *does* support COM, how the hell do you *use* it?

By the way, that was the link for implementing COM in your own code if you 
don't already have a COM interface built into your language. COM is 
basically a way of invoking object-oriented actions to a server (where 
"server" means your own or some other address space).

If you already have a library, you invoke it from your scripting language by 
using whatever function the scripting language has for creating an object 
from a COM server, then you just call it like it was a local object.

In Tcl, for example, you can do this
http://www.vex.net/~cthuang/tcom/chart.html
to start a copy of Excel and then create a spreadsheet and chart the values 
in it.

Or you can do this:
http://www.vex.net/~cthuang/tcom/server.html
to create a "server" side, which is to say, a program that can create COM 
objects for others to use.

VB6 had all this stuff built in, so you'd just say "hey, this is a com 
object" and you could instantiate it and call it and everything. That's what 
made VB6 so popular: if you wanted to do something funky with an excel 
spreadsheet, you could write a COM object in VB6 and call it from the Excel 
spreadsheet in a macro and have that COM object talk to other COM objects 
like web servers and so on.

Most of the languages that support COM just say "here's how you create a COM 
object, here's how you create the server side, go for it." And you mostly 
don't have to worry about how it works inside until something breaks. In a 
language that supports COM already, it's not noticeably harder than writing 
or invoking DLLs.

You may think it's difficult because you're trying to use it from Haskell, 
and COM is OO.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message