Q:Newbie ActiveX questions

Hi there,

INTRO, you might skip this in case your time is as costly as mine:
goto PROBLEMS/QUESTIONS

I am a complete newbie to ActiveX's.

As any serious C++ programmer I have a lot of books,
among which the famous:

Sams teach yourself...
Unleashed
HowTo

and about ActiveX's, COM and IDL :

ActiveX Controls Inside Out ( 2nd Ed.,MicroSoft, Adam Denning )
The Essence of COM with ActiveX ( 2nd Ed., PTR, David S. Platt )
COM IDL & Interface Design (WROX, Dr. Al Major )

The problem is this:
I am not too lazy to read all this stuff, but I am pressed for time,
and need practical knowledge ( NOW !!! ( sorry, actually I am the polite
kind of guy, that appreciates your effort most highly ) ).

Although at home I have some problems with registering ActiveX's,
I have let CBuilder 4 Pro succesfully compile, build and register
some simple ActiveX's at work.

To be specific: a VCL class derived from TButton and a stuffed TActiveForm
and some more ( TStringGrid etc ).

In all cases CBuilder took care of generating the code necessary
to fire ( default-)events in a COM-container.

PROBLEMS/QUESTIONS

I succeeded in adding own properties and methods via the type library
editor,
but don't know how to add custom events. Of the same order is this
question:
if CB has made interfaces with properties, methods and events, how do I
dispose some
of them savely and which sections of code do I have to delete?
I would also like to know if its possible to fire events in any window my
com-object
has the handle (HWND) of, not just its own container.

The property and method part is what I get working somehow.
The events-part is more problematic ( The only working events so far,
are the default-ones of the VCL-component/form ).

Second, if you have a form, it usually has instances of other classes,
with methods and attributes, which in C++ can be accessed in cascade,
as in Form1->RichEdit1->Text.

I want this cascading facility also in my ActiveX's and realize that
I have to add additional interfaces, and methods/properties which
return com-handles. Actually anything which is __published or public
and accessible through MyActiveForm->
must be accessible through com-handles ( or interfaces or whatever ).
Is it possible to have the __published and public parts, accessible through
MyActiveForm, get automatically in an ( or more ) interface(s)?

Its easy enough to click icons or the right mouse-button in the
type-library-tool,
in order to add an interface, dispinterface or coclass, but I've not the
slightest
idea of what exactly I am doing than, yet. ( I am honest, though ).
How can I do something intelligent with it, eg combine this with C++
classes?
All I want is to access my own methods in MyActiveForm or its instances
( eg MyActiveForm->TreeView->FullCollapse(), or whatever ),
pass own events to the container and read and write own properties,
which is what ActiveX's are all about, isn't it?
( The ActiveX's I make are used by a database-language called Progress (
for work ),
  at home I might use them in CB as well ).

How can I make use of TComponent:ComObject?
After doing a find in the help on its type ( _di_IUnknown ), I came across
the intriguing TInterfaceList. What's it for and more important: how do I
use it?

If I have some own classes which I want to turn into ActiveX's, is it
smart to derive them from TComponent, if otherwise it would derive from
TObject
by default? What is the dirty non-VCL non-MFC route ( eg asm if I want very
small
.ocx's )? Whats the overhead in terms of size, imposed by frameworks like
MFC, ATL or VCL?

I have understood there are three kinds of interfaces:
1) One using IDispatch, getting IDs via GetIDsOfNames, then calling Invoke,
2) The dual interface, extending 1) with vtables
3) dispinterfaces, the same as 1) avoiding GetIDsOfNames.

I am interested in making ActiveX's with this three-fold interface
capability,
letting CBuilder doing most of the work ( for now, I want to know the ins
and outs
downto assembly-level later ). I know CBuilders type-library-tool has an
option 'dual'. How do I get the third for free? ( I guess it makes use of
the TLB
to get the dispID's).
How does the IDispatch::GetIDsOfNames interface make use of vtables, that
is
how does CBuilder and/or the ATL give you this interface for free like
magic?
Same question for dispinterfaces, since the unleashed book ( CB3 ) suggests
on
pages 827 and 829, you can get this one for free too.

In the book accompanying CB4 Pro it looks like everything goes completely
automatically:

The properties, methods and events of the form ( or VCL-class ) become
those of the ActiveX.
Why do I have to go to the type-librabry-tool to add properties and
methods,
press refresh and fill in the empty spots? That is:
why cann't I go from a form, add pubished, public , protected and private
methods, make properties and closures for events and let CBuilder take care

of the rest? ( The __published and public part could be the interface of
the ActiveX ).
In this respect, deriving from a VCL-class is easier: you can deside later
to turn it in
an ActiveX. In case of a Form this doesn't seem practical.

I noticed the VCL-class which is turned into an ActiveX is wrapped up
somehow.
I don't quite follow the m_VclCtl stuff and hestitate to deside what has to
go
where. There's an astonishing set of files and classes. Somewhere hidden in
between
all off this is your VCL-class. Then you have the Impl-thing, the
ATL-thing,
the TLB-thing and so on. How do these relate to each other and to the
different kind
of interfaces?
To me, especially events are hard to cope with.
What's meant by m_VclCtl->OnActivate = OnActivateEvent,
the Fire-stuff and all the mapping-stuff ( BEGIN_COM_MAP ) and the method
InitializeControl().
Where is all that defined? ( I know an event is both a property and a
closure, I do understand
the VCL-basics to some extent; it's the whole COM-stuff thats new to me,
and complicated above all ).

Specifically I would like to know for each kind of interface ( IDispatch,
disp, vtable )
how the event-passing to the container takes place, and what has to be
defined where,
if I would like to do it manually, without the type-library-tool.
( As a means to understand the whole process ).
An overview of what gets generated and for what purpose and belonging to
which interface,
would do, too.
Until now I have used CB to make ActiveX's and used Progress to test them.
I will myself take the trouble of taking an ActiveX and placing it on the
component-palette, then using it and single-step through it, if this is
what it
takes to understand whats going on. From Progress I can merely see one of
three things:
1) It doesn't work
2) It doesn't work completely
3) It works

The why and how remains in the dark.

Could anyone give tips on where to set breakpoints and how to not only test
the vtable
approach, but also the IDispatch and dispinterface approach from CB?

Cann't I derive a form from TActiveForm and go from there?
Its possible to derive from other VCL-classes and turn the result into
an ActiveX. Why does it seem to me that in the case of Forms, you
__must__ use TActiveForm?

Apart from the Unleashed book, the other ActiveX books suppose "the other
C++ compiler" with MFC. I know that CBuilder supports MFC, but I want
to stick to the VCL for now. How should I relate the material in eg. the
"inside out book" to the practice of building ActiveX's with CB and VCL?
The ActiveX stuff is new to me, so how am I supposed to see it from
MS point of view and use this knowledge in CB? Its complicated enough as
is,
and I think that adapting the examples requires the experience I don't have
about both ActiveX's and MFC. So these books can help me understand if I
understand
first already, you see?

Three final things:

I made a form with a menu, and after placing the resulting ActiveX in a
Progress com-container, the menu vanished. I know that ActiveX's are
supposed
to be light controls, extending capabilities of some language, and that the
ActiveX
should contribute modestly, not being your total application. But if I am
self-conceited :)
and still want my ActiveX appear like one or more windows with as much as
menu's as I like?
Do I have to create a dynamic instance of a form and Show() it explicitly?
An CB ActiveX on a
Progress-form with a Progress-menu would be the other alternative,
but I highly prefer C++ over Progress
( Lucky me that I have succeeded in proving the usefulness of C++, so I can
use it at work!
  The rest of us think they can program, but they do baby-talk:
  not even slightly OOP, and only about "FOR EACH customer" or "FIND order
OF customer".
  This dressed with a sauce of "widgets" ( windows-controls ) on a
pre-Visual-Basic-level.
  ( Yes, it can be made more easy and more dull and less
expressive/powerful, still ).
  C++ is a real challenge! ).

What should I do in order to be able to have multiple instances of an
ActiveX in an form?
I noticed that extern variables get shared, and found weird interactions
with events,
after placing multiple TButton-derived ActiveX instances ). As far as I
know,
Progress itself is single-threaded ( client-side ). What threading-model
and locking-stategy
should I use? ( Idem for WWW ).
Last but not least:

From the same Progress I was talking about, I can access an ActiveX in two
ways:

define com-container as com-handle init control-frame:com-handle no-undo.
   /* the control-frame is a wrapper for a com-container */
define com-object as com-handle no-undo.

com-object=com-object:MyActiveX. /* MyActiveX=filename minus .ocx */
Now "com-object" gives me direct ( as opposed to the 2nd way ) access to
one instance.

The second way:

define com-container as com-handle init ... no-undo.
define collection as com-handle no-undo.

collection=com-container:controls.

Now I can access :
collection:Item(1), being the first instance.

"com-object" from the first example is equivalent to "collection:item(1)"
in the 2nd
example.

Can anyone give me some insight in these collections,
that is: how does the ActiveX in combination with its com-container support
multiple indexed instances, and what do I have to do to have my ActiveX's
like that?
I do question this here, since the Progress control-frame is merely a
wrapper
for a com-container, which is a gift from Bill, as I understood it. From
there its all the same,
whether using Progress, VB, CB or whatever. So the collection-thing is a
COM-feature,
not a Progress feature, I think.

After reading this short novel, you now might take a break.
If you feel like it, you might
1) give me some hints on an own event
2) give me some hints on adding interfaces, coclasses and what else is
needed for cascade-access.
3) if you are very persistent: answer some of the other topics

1) + 2) make me look good at work, and practice is a place to start
3) = intellectual climax, that is: knowing how stimulates!

Thanks, thanks, mucho thanks!

RRO.
r...@euronet.nl