Acessing ActiveX Component Interfaces/ Library not registered

Florian Storck

Hi there, I've some problems accessing my ActiveX control from a VBScript/JScript. The control can be successfully initialized and acessed via the tag. The problem is, that I've to retrieve additional objects/interfaces from the control, which are all defined in the typelib embedded in the control. This looks somehow like this: var ObjInst = new Object; // returns another IDispatch interface of an internal object ObjInst = Control.GetInstance(); // creates a "Library not registered" error ObjInst.Method(); Because everythings working fine from CPP/VB when compiling, I would like to know, whether I have to register or reference the typelib somehow in the html code or somewhere else, or whatever may cause this error. I can view the typelib in the OLE viewer supplied with visual studio, so the registration can't be that faulty in my opinion. My thoughts were, that acessing a reference to a IDispatch interface should be generally no problem in JScript/VBScript. Thanks for any suggestions. Florian

lemur2

Hi Florian, It may not be related, but at work yesterday, I was having a similar problem when trying to use a legacy C++ OCX from a script. What I found was that the control was written with MFC and was specifically blocking access to the dispatch interface. I was able to override the IsInvokeAllowed() to return TRUE which solved my problem. As I said, it may be completely unrelated, but its worth looking into if your control was written using MFC. Regards Kev

Florian Storck

Hi Kev, thanks for your fast reply! Well, the control is originally based on MFC, so I think this is worth a try. Bye, Florian

Florian Storck

Hi kev, bad news so far. Overriding doesn't helps here. The function gets called, but generally returning TRUE hasn't had any effect. I changed it for crosschecking to FALSE and got a different error, when trying to invoke the function which returns the IDispatch reference to the internal object I want to expose. But in general I'm right, when I suppose that JScript/VBScript should automatically generate a wrapper for a returned reference to an IDispatch interface ( IDispatch* in the used function) ? Or have I anything forgotten in that case ? My exposed Control doesn't implements these additional interfaces, but they're all defined and accessible in the corresponding typelibrary. Bye, Florian

lemur2

Hi Florian, I'm not too sure if I'm fully understanding your problem - it looked at first glance as if it was the same problem as mine. To anyone else reading, if I put my foot in it, please correct me - in no way do I claim to be a COM wizard. Just been around the block a couple of times, learning as I go... X| Basically, if you access a COM component or control using a scripting language, you're limited to whatever functionality is available on the default interface of the component which must be an IDispatch-based interface. Calls are made simply by the scripting host mapping the method or property name (string) onto an id (int) and passing this id along with parameter information to the IDispatch::Invoke method. If your control implements only custom (IUnknown-based) interfaces, you won't be able to access its functionality from a scripting language. If an MFC wizard was used, you'll almost certainly have at least part of your component exposed via a dual interface. If you've added any further secondary interfaces though, these won't be accessible to the scripting language. Can you give me a bit more detail about your component - maybe attach an IDL file or even the coclass definition from the IDL file? Kev

Florian Storck

Hi Kev, well, I suppose you're getting to the core there. All interfaces are implemented as dual, automation. It was a former MFC Control, which has been added ATL support. The control itself exposes their standard dispatch interfaces. The basic definition is somehow like this:

[ object,
uuid(),
version(1.0),
dual,
oleautomation,
pointer_default(unique)
]
interface IMyIF: IDispatch
{

[id(0x00020001)] HRESULT fn1();
};

  \[ uuid(),
dispinterface \_DCTL
{
    properties:
   

	methods:                                                                     
  
  \[id(101),\]  \[unique\] IMyIF\* GetMyIF();
  \[id(102), propget\]   IMyIF\* ActiveMyIF();
 
};


\[ uuid(),     
      control 
\]
coclass CTL
{
            \[default\] dispinterface \_DCTL;
	\[default, source\] dispinterface \_DCTLEvents;
};

All objects to be exposed are maintained internally in the control, an the coclass definition of IMyIF is noncreatable. So all I do is, returning the IDispatch reference pointer to an existing instance within the control via the GetMyIF() function or property. The funny thing is, that I downloaded the ActiveX control pad from Microsoft today, which shows me the methods implemented by IMyIF when clicking the propget method ActiveMyIF, but it's not working either. I suppose, somehow only access to the direct implemented Dispatch methods of the control is possible. But I think there must be some way, to generate objects based on the other exposed IDispatch references. At least, IDispatch should be working, because it's runtime callable. Weird,weird. Thanks again for your suggestions, Florian

Jorgen Sigvardsson

JScript and also VBScript behaves really weird if you miss to tag out parameters properly in the IDL definition. Make sure they are [out, retval]. An eye for a tooth will only make you see weird things.

Florian Storck

Hi Jörgen, well, that 's maybe worth a try. Thanks for your suggestion ! Bye, Florian