>>> I also figured that the only reason that you can (say) embed an Excel
>>> spreadsheet in a Word document is because both products are produced
>>> by the same company.
>>
>> No no no. That's the whole *point* of COM. That's why there's a standard
>> interface definition language and such.
>
> See, I've always assumed that the glitering world of native Windows
> GUIs, IPC, DLLs, COM, etc. are all behind closed doors, accessible only
> to people who know how to write really low-level Windows code. And I've
> always assumed that the really /good/ stuff (like embedding one
> application inside another) is accessible only to Microsoft themselves.
> (Or anybody who pays really vast sums of money. People like Symantec.)
>
In reality, if you know what you are doing, and your own application 
supports it properly, you can even link things within VBScript. The 
problem being that "some" functionality gets seriously screwy, if its 
not right, and MS' explanation on how to do it is... less than helpful. 
I seem to remember that the example they had for doing it super-low 
level, which you need for full functionality of "embeddable" objects, 
like MS' own picture object, only showed how to instance a single 
object, not handle them as a collection, or respond to clicks and other 
effects on *all* of them at the same time. But, if you use IE, or even 
their shell script system, these things are handled by code already set 
up to do that sort of thing. Same if you are using a compiled language, 
like the full VB (not the script).

All in all, while, in principle, you can do all sorts of fancy shit with 
them, its still easier, unless you know how to do all the object 
collection, respond to stuff instanced "after" the application is 
running, i.e., late linked, without the application knowing before hand 
what the interfaces are, etc., then your prior assumption is pretty 
close to accurate. If all you are trying to do is say, link to an excel 
document, to pull out a few known cells of data, to do other 
calculations, but you don't have to actually "display" the page, its 
damn simple. Otherwise, you end up pulling your hair out trying to find 
example code of how to actually do that stuff, if your "intent" is to 
access it using late binding, which, as I said, means that your program 
doesn't already "know" how to handle some of the interfaces, but has to 
set them up once running.

Mostly, the problems in that case all come down to "your" application 
responding to messages from the control though. Which is why a spreed 
sheet can be "read", but not displayed easily. The former requires 
merely making a request, which is "immediately" returned, via the 
request itself. Displaying it require telling it who the "parent window" 
will be, then trying to get your application to "see" messages via the 
Windows messaging system, which tell it where you clicked, what you 
moved, etc. Your own application is effectively blind to these, without 
some serious behind the scenes support, or unless you "prelinked" the 
object, i.e., added it as part of the project, instead of creating the 
connection later. This is especially obvious when you run the VBScript 
engine in your own application, only to discover that it has 
CreateObject, but that the, "Let clicks and things be handled for this 
object", function is actually an IE feature, not something in the script 
engine itself, so you have to somehow design one for yourself. The last 
time I tried to figure that one out I gave up when the guy writing the 
client that used scripting implemented the features directly anyway. lol

Post a reply to this message