Hey C.Hahn,
first thanks for your answer!
I want to use the .wsc component as an ActiveX Server.
For Example, I can access this component from a .wsf
windows scripting host or from IE with a call
in JScript like:
myComponent = new ActiveXObject("MyComponent.wsc");
I can also access this .wsc also from VB or VC++.
Even from Labwindows/CVI 5.5 I can access this component by a call like:
const IID IID_IUnknown = {0x00000000,0x0000,0x0000,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46};
const IID IID_IDispatch = {0x00020400,0x0000,0x0000,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46};
{
error = CA_CreateObjectByProgIdEx ("MyComponent.wsc", NULL, &IID_IUnknown, 1, LOCALE_NEUTRAL, 0, &handle);
error = CA_MethodInvokeEx (handle, NULL, &IID_IDispatch, 1, CAVT_VARIANT, &result, 1, intPoi, 1);
}
When I now use the ActiveX Control Wizard in Labwindows/CVI 5.5 to
create a .fp file from the .tlb file, wich was generated by microsoft for
this .wsc component, the wizard generated all needed files. Without any errors.
But when I try this:
error = ScriptletTypeLib_NewAutomation (NULL, 1, LOCALE_NEUTRAL, 0, &handle);
it crashes. The error code indicates that the interface is not supported.
As I looked through the code, generated by the wizard, I found, that the wizard
does not use the same IID like I use in the example above. It generated registry entries,
which are pointing to the same olexxx.dll, as the IDISPATCH interface but it does not work.
It is easy to understand that my example is not very practicable.
You have no function names, just the function numbers. Not very nice for other
programmers.
The other problem is, that some programmers want to use this component
in LabView. But as you can think of, they have the same problems to
access this component, like I have it with the ActiveX Control Wizard.
For us the last possibility is to write a .dll in Labwindows, so LabView
programmers have access to the Component functions.
But I think there must be an easier way to integrate this .wsc functions.
Do you have an idea?
