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
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
