I have finally found a need to generate my own COM objects (Dispatchable).

First, forgive me, i dont have examples with me so i will try to explain my question a clearly as i can (i decided to do the research on this as a vacation project ~ didnt think it would take alot of work so i could spread this side project over the week)

1) I have disected the COM Object Createor tool that XTreme had made eons ago, using simple java scipts and HTML. In the end its nothing special since it uses exclusively ernie's CoLib includes and lib anyways.

2) Looking at the generated code, it makes an include files that would be similar to the output of Tbl2Inc.exe, but for your new COM object. This part is nothing new to me. The IDL file, and its conversion to TBL is also straight forward. It also produces the DLL definition file, and again, i have no problem.

3) The assembly listing is in two major parts, a data segment with the COM object layout, and the code segment with the new methods/property handling functions.

I checked up all the CoLib macros in the include, and i follow the various maps (Class/Interface/Typelib) as well as the Object structure and object data structs.

However the CLASSMAP is made public, and i assume links with a number of functions in the CoLib that are not clearly shown or indicated. So there is a considerable ammount of black box magic going on that i can't trace down and follow.

Namely the DLL*.asm files are linked into the DLL from the CoLib.lib, and probably others. So in my study of a com object im falling short here of seeing *exactly* how the assembly is layed out for the COM dll file. Colib is quite vast and im sure not everything is pacted into the final product. Is there anyway i can find out what is the extras that is also included?

Either a listing of the asm files (from the colibfiles directory) or a basic outline of what goes in using these vtable maps, and suporting functions. I assume the IUnknown and IDispatch interfaces must also have functions within colib to generically handle their methods for your new object?? Cause the ASM listing only showns the newest methods and properties??

Anyways some help here would be nice.
I also tried Japheth's ASMControl example, but no offense, its very unclear with so many macros...

Regards,
:NaN:
:stupid: :stupid:
Posted on 2003-09-03 12:29:24 by NaN
Oh ya, im currently reading through Ernie' doc on COM/Colib... it may have some answers im looking for... but if you think you have something to add please feel free to share your thoughts ;)

:NaN:
Posted on 2003-09-03 12:58:11 by NaN
Hi NaN,

if your object is just an automation object (exposes IUnknown, IDispatch and your custom interface), forget about the ASMCtrl example (and colib). The macros are mainly for OCX controls with a user interface, needing a bunch of interfaces like IOleControl, IOleInPlace....
So implementing an IDispatch should be trivial for someone with your skills :) .

Japheth


I just took an older version of AsmCtrl (without macros) ant threw away the OCX control stuff (so its a pure automation server now) and uploaded it on my site. If you like download it from here
Posted on 2003-09-04 02:17:46 by japheth
With *my* skills ;)

You give me too much confidence... im very thick headed, but once it gets in there it tends to remain. However, breaking new ground like this is always a slow and maticulous journey.

As well, your recient addition to your site is more than expected! Thank you very much. Im very impressed to be given working CClassFactory and CDispatch files, since i enjoy your COM in ASM convention the most, this just simplified alot of overhead....

Thanks again for your help Japheth!
Its very much appreciated,
Regards,
NaN
Posted on 2003-09-08 20:52:58 by NaN
I'm Baaaaak


sorry, been away then caught the worlds worst cold flying back


Anyway...

Yes, CLASSMAP needs be public so that the CoLib functions can read it. CoLib basically reads the map for each coclass template so the boilerplate code works.

CoLib just impliments IUnknown for you, using CLASSMAP to fill in the blanks (mostly for QueryInterface).

The IDispatch implimentation in CoLib is just a wrapper around the COM type lib driven implimentation. IDispatch is hardly a trivial interface to mess around with, and with an existing implimentation already on every windows machine why build one not as good?
Posted on 2003-09-10 21:17:23 by Ernie
I assume your eluding to aggregation (if i spelled it correctly)?

This is one of the biggest grey areas im finding in all the examples i have dug up. Are they offloading responsibility directly to another registered object, effectively inheriting. Or are they making their own phseudo version for every COM object, of interfaces like IUnknown and IDispatch....

If aggregation is the way to go, then how do they work inside their black boxes, and how is my new com object to prepare for them to work properly...

As you can tell agregation is something i think i understand in Theory, but in actuall practice is a complete mystery due to all the *little things* you overlook when generalizing in Theoretical discussions...

:NaN:
Posted on 2003-09-10 21:58:14 by NaN