ActiveX and RR

[Dar Scott]

On Aug 9, 2004, at 3:56 PM, Chipp Walters wrote:

> Regarding ActiveX (from Chris):
>
> 1) He believes it's easy to add (in fact, we have a ActiveX 
> instantiator in our XConnector code for Hemingway) with the following 
> caveats:
>
> a) You would need to know the CLSID of the ActiveX control you wanted 
> to add (this could probably be done inside of RR using a Registry 
> browser function).


> b) You could display the ActiveX control/player easily on a card

Many automation COM services do not need a control.  I realize that 
most folks want the control, but where I could have used this over the 
past couple years, I have not needed the control.

> c) You could set properties and call methods (assume you know the 
> correct syntax)
>
> All this is well and good...and in fact is how RB deals with them. The 
> two major hard parts are:
>
> 1) 'event trapping' or sending events back and forth across the RR 
> boundary.

The calls should be more straightforward.  The callbacks may be a 
problem and there may be a need to get across a thread boundary.  In 
looking at similar problems, I think the Revolution app may need to 
poll for the callbacks.

> 2) 'type marshalling' or converting RR strings to the appropriate 
> Windows API type.
>
> The first can be done thru custom code in an external or an engine 
> modification. Type marshalling is a bit more difficult and would make 
> sense to have an engine modification in order to do this properly. 
> Things like pointer handles and arrays are most difficult. This would 
> mean we would need some way to convert strings to variants.

I don't think this is as bad as it sounds.  The first step is to come 
up with the right mapping of types.  The pointers are known and are not 
arbitrary so a scheme can be set up for those.  The implementation step 
might be tedious but half can be done in transcript.

> Plus, there's the whole issue of unicode which makes things even 
> harder...

Well, Revolution does handle unicode values and for the first version 
it might be OK to assume ASCII.

Such a thing would have been handy for some DCOM work over the past 
couple years, but I don't know how much that might come up again.  I 
have toyed with the idea of a generic dll interface, but that has crash 
risks if the developer gets the interface wrong.

I have found COM to be tedious.  That might mean more work for whomever 
builds this, but it will mean less work (if done well) for others.

Dar Scott