I want to expose methods of CUIAutomation COM class objects to scripts I load and run through my Active / Windows Script application (I am not implementing a script engine, I am using one, specifically the "JScript" engine). The script host is normally able to expose any IDispatch-implementing object automatically, but CUIAutomation class does not implement IDispatch. Calls to QueryInterface for an IDispatch pointer on the object return E_NOINTERFACE.
My entire question, on which I elaborate below, basically boils down to this: is it possible to implement dispatching for an object that doesn't implement IDispatch? I bet having type information for the coclass of the object would be a necessary (and possibly sufficient) requirement, if it were possible. If it is possible, what is wrong with my attempt to do so as explained below? What are my alternatives?
As mentioned, my solution centers around my hypothesis that if I should have the type information (ITypeInfo) for CUIAutomation coclass, then I should theoretically be able to do runtime dispatching on objects of said coclass, even without it implementing IDispatch but just through methods of ITypeInfo like GetIDsOfNames and Invoke. Practically, I'd design a class of my own that does implement IDispatch, wraps a CUIAutomation object (or any IUnknown for that matter that I can pair with proper type information) and delegates member dispatch to the wrapped object.
I have been successful in loading type information for at least the CUIAutomation coclass -- it's all in the Windows Registry -- by locating the path to the module that implements it and using the LoadTypeLib procedure:
(Note: I have assertions that check if calls succeed (by comparing to S_OK or ERROR_SUCCESS etc -- depends on what's code for success), but I omit said error checking in the snippets, for brevity -- if a call isn't checked for return value there is invariably an assertion in place around it, as described)
/// Return zero if and only if successful
int LoadTypeInfo(LPOLESTR szCLSID, ITypeInfo * * ppTypeInfo) {
HKEY hRegKeyCLSIDs;
RegOpenKeyEx(HKEY_CLASSES_ROOT, "CLSID", 0, KEY_READ, &hRegKeyCLSIDs); /// Only need to do this once through application lifetime, but here for context
HKEY hRegKeyCLSID;
RegOpenKeyEx(hRegKeyCLSIDs, szCLSID , 0, KEY_READ, &hRegKeyCLSID);
BYTE data[MAX_PATH];
DWORD cbData = sizeof(data);
RegGetValueW(hRegKeyCLSID, L"InprocServer32", NULL, RRF_RT_REG_SZ, NULL, data, &cbData);
ITypeLib * pTypeLib;
LoadTypeLib((LPOLESTR)data, &pTypeLib);
return (pTypeLib->GetTypeInfoOfGuid(CLSID, ppTypeInfo) == S_OK);
}
The delegating DispatchProxy class is designed as follows:
class DispatchProxy: public IDispatch {
private:
IUnknown * pUnknown;
ITypeInfo * pTypeInfo;
public:
DispatchProxy(IUnknown * pUnknown, ITypeInfo * pTypeInfo): pUnknown(pUnknown), pTypeInfo(pTypeInfo) {
/// `pUnknown` is the object that doesn't implement `IDispatch` and `pTypeInfo` is the type information for objects like what `pUnknown` points to.
}
/// Omitting `AddRef` and `Release` -- these are rather standard.
HRESULT STDMETHODCALLTYPE DispatchProxy::QueryInterface(REFIID riid, void * * ppvObject) {
if(ppvObject == nullptr) {
return E_POINTER;
}
else
if(riid == IID_IUnknown || riid == IID_IDispatch) {
*ppvObject = this;
((IUnknown *)*ppvObject)->AddRef();
return S_OK;
}
else {
*ppvObject = NULL;
return E_NOINTERFACE;
}
}
/// NOT returning any type information -- explanation below, if you're surprised
HRESULT STDMETHODCALLTYPE DispatchProxy::GetTypeInfoCount(UINT * pctinfo) {
*pctinfo = 0;
return S_OK;
}
HRESULT STDMETHODCALLTYPE DispatchProxy::GetTypeInfo(UINT iTInfo, LCID lcid, ITypeInfo ** ppTInfo) {
if(iTInfo != 0) return DISP_E_BADINDEX;
_ASSERTE(*ppTInfo == NULL);
return E_NOTIMPL; /// Even though type information for the object being delegated to, is available, obviously, I am unsure whether it technically is valid for `DispatchProxy`, which may have a completely different, incompatible, layout. Granted, `E_NOTIMPL` isn't part of the contract for this method, but like I said -- I am unsure about this one.
}
HRESULT STDMETHODCALLTYPE DispatchProxy::GetIDsOfNames(REFIID riid, LPOLESTR * rgszNames, UINT cNames, LCID lcid, DISPID * rgDispId) {
return pTypeInfo->GetIDsOfNames(rgszNames, cNames, rgDispId); /// Returns S_OK, all good. Also tried `DispGetIDsOfNames(pTypeInfo, rgszNames, cNames, rgDispId)` with same result
}
HRESULT STDMETHODCALLTYPE DispatchProxy::Invoke(DISPID dispIdMember, REFIID riid, LCID lcid, WORD wFlags, DISPPARAMS * pDispParams, VARIANT * pVarResult, EXCEPINFO * pExcepInfo, UINT * puArgErr) {
return pTypeInfo->Invoke(pUnknown, dispIdMember, wFlags, pDispParams, pVarResult, pExcepInfo, puArgErr); /// Fails with `E_NOTIMPL`. Also tried `DispInvoke(pUnknown, pTypeInfo, dispIdMember, wFlags, pDispParams, pVarResult, pExcepInfo, puArgErr)` with same result
}
};
On a related note, I need a way for the script to obtain references to objects like that of the CUIAutomation class, before they (scripts) can call methods on these. I straight up allow scripts to create COM objects of specified CLSID by exposing a createObject method on a "global" IDispatch-implementing object, much like VBScript's CreateObject function or new ActiveXObject(progID) in Internet Explorer back in the day. It uses CoCreateInstance to create an object of the COM class identified by specified CLSID:
HRESULT Global::CreateObject(VARIANT * pvCLSID, VARIANT * pvResult) {
_ASSERTE(V_VT(pvCLSID) == VT_BSTR);
CLSID CLSID;
CLSIDFromString(V_BSTR(pvCLSID), &CLSID);
IUnknown * pUnknown;
CoCreateInstance(CLSID, NULL, CLSCTX_INPROC_SERVER, IID_IUnknown, &pUnknown);
IDispatch * pDispatch;
HRESULT hResult = pUnknown->QueryInterface(&pDispatch);
if(hResult != S_OK) {
_ASSERTE(hResult == E_NOINTERFACE);
ITypeInfo * pTypeInfo;
if(LoadTypeInfo(V_BST(pvCLSID), &pTypeInfo)) { /// No type information was available -- not much choice but to return the created object as `IUnknown`
V_VT(pvResult) = VT_UNKNOWN;
V_UNKNOWN(pvResult) = pUnknown;
return S_OK;
} else {
pDispatch = new DispatchProxy(pUnknown, pTypeInfo);
}
}
if(pvResult) {
V_VT(pvResult) = VT_DISPATCH;
V_DISPATCH(pvResult) = pDispatch;
}
return S_OK;
}
A script can create a CUIAutomation object and get a reference to the new DispatchProxy wrapping it like so:
uiautomation = createObject("{ff48dba4-60ef-4201-aa87-54103eef594e}");
It should then be able to call methods (here GetRootElement) on the object:
uiautomation.GetRootElement(/* parameters */);
Unfortunately, the pTypeInfo->Invoke call at the heart of all of it returns E_NOTIMPL. That's the immediate problem, as of now.
What is not implemented, and why? The member ID (dispIdMember) matches what pTypeInfo->GetIDsOfNames writes earlier, and the latter returns S_OK, so the member ID, according to it at least, is valid. I don't think the parameter format has anything to do with it either -- I would expect another error code from the pTypeInfo->Invoke call if it did.
Making GetTypeInfoCount write 1 as type information count and writing pTypeInfo as result of GetTypeInfo has no effect on the result of subsequent ITypeInfo::Invoke call -- it still fails.
I also tried using the actual IUIAutomation interface type information (pTypeInfoDefaultInterface in the snippet below) that I obtain on the original coclass ITypeInfo object, as opposed to that of the coclass itself, even though documentation sort of implies ITypeInfo::Invoke may recurse into referenced types automatically:
HREFTYPE hRefType;
pTypeInfo->GetRefTypeOfImplType(0, &hRefType);
ITypeInfo * pTypeInfoDefaultInterface;
pTypeInfo->GetRefTypeInfo(hRefType, &pTypeInfoDefaultInterface);
The effect is the same, regardless of whether the interface or the coclass type information is used -- ITypeInfo::Invoke returns E_NOTIMPL.
What am I doing wrong? Am I missing some crucial information about COM, or dispatching, or what type information can do for me? I don't write IDL files, and the DispatchProxy isn't part of some COM server, it's strictly internal class for my application. I looked at the virtual function tables that Visual C++ lets me peek at, and I also did some investigation with GetFuncDesc on the type information -- what it fills out seems to be solid -- there is everything -- names and parameter type and count for every expected method that I am attempting to invoke. The pointers are valid and available.
I admit that at least with GetRootElement which expects a pointer to a pointer to an object, dispatching such method from a script that may not even be able to pass parameters of such type, may be the culprit. But according to documentation, ITypeInfo::Invoke should probably return E_INVALIDARG or DISP_E_EXCEPTION, in such case.
I tried playing around with CreateStdDispatch, too, but two things irk at me -- why shouldn't the above work, for starters? And second, I don't understand exactly what dispatches from where with CreateStdDispatch and which pointers go as which arguments. I suppose unless it's the idiomatic alternative here, it's not my actual question, but if it will help my case I am all for getting an explanation on what exactly does it do and how to plug it in.
Related
If a pointer is passed to a function for read only, then this pointer is an IN parameter.
If a pointer is passed to a function for read only, but this function makes a copy of the pointer to have access to it in module related functions for read only operations, this pointer is still IN.
If the function still uses the pointer as read only, but the other module related functions use the pointer for write operations, what does that make the pointer?
An IN parameter, but without const? An in/out parameter?
Example of what I mean:
class SteeringWheel {
public: float rotation;
public: SteeringWheel(void) {
this->rotation = 0.f;
}
};
class Car {
private: SteeringWheel *steeringWheel;
public:
/**
* #param[?] steeringWheel Is the steering wheel in or in/out?
*/
Car (SteeringWheel *steeringWheel) {
this->steeringWheel = steeringWheel;
}
/**
* #param[in] degree Steering amount in degrees.
*/
void steer(float degree)
{
this->steeringWheel->rotation += degree;
}
};
int main(int argc, char **argv)
{
SteeringWheel steeringWheel();
/* car() uses steeringWheel as read only. */
Car car(&steeringWheel);
/* steer() uses steeringWheel from car() to write. */
car.steer(50.f);
return 0;
}
I believe that the in and out specifiers do not exactly mean what you think. From the doxygen documentation of the param tag:
The \param command has an optional attribute, (dir), specifying the
direction of the parameter. Possible values are "[in]", "[in,out]",
and "[out]", note the [square] brackets in this description. When a
parameter is both input and output, [in,out] is used as attribute.
The direction of the parameter usually mean the following:
in: The parameter is injected into the function as input, but not written to.
out: The parameter is injected into the function, but not as input. Rather, it is written to by the function.
in, out: The parameter is injected into the function as input and is eventually written to by the function.
In your example:
/**
* #param[?] steeringWheel Is the steering wheel in or in/out?
*/
Car (SteeringWheel *steeringWheel) {
this->steeringWheel = steeringWheel;
}
I think the steeringWheel parameter is in because you inject it and use it in your method. However, you never write to it (i.e. to the parameter itself), so it is not out. In other words, you only use your method to inject an address to your function, nothing else. The same apply for your second method, where you inject the degree parameter, but never write to it.
To clarify a bit more on the meaning of in and out, here is an example of an out parameter:
/**
* #param[out] p_param We write to the parameter!
*/
void makeFour(int * p_param)
{
*p_param = 4; // Out because of this line!
}
Notice that we write a new value directly into the parameter. This is the meaning of out: information comes out of the method through the parameter. You can now write:
int main()
{
int myInt = 0;
std::cout << myInt; // prints 0.
makeFour(&myInt); // p_param == &myInt here.
std::cout << myInt; // prints 4: the method wrote directly
// in the parameter (out)!
return 0;
}
Hope this helps!
It is not easy to decide, but I would still mark your parameter as in,out (or out), as it is a pointer to a non-const object, and you may change the state of that outside object directly or indirectly later - as in your example.
Marking it in hides the detail that the pointed SteeringWheel object may change later upon usage of Car.
Also, it can puzzle users why an input only pointer parameter is not marked const.
Making it in,out may not be accurate completely, but is surely more error prone.
An alternative could be something like the following (a note regarding the lifetime of the SteeringWheel should come handy here anyway):
/**
* #param[in] steeringWheel Pointer to the SteeringWheel object.
* #warning The memory address of the pointed object is saved.
* It must outlive this object, and can change upon usage of this object.
*/
Car (SteeringWheel *steeringWheel) {
this->steeringWheel = steeringWheel;
}
But I would just probably stick with marking it in,out.
Specifying the direction of parameters in C++ may be complicated, and frankly speaking, I am not too much in favor of them, as having tokens for pointers, references, and the keyword for constness provide enough information in the signature on how a parameter may be used. Thus, marking it in the DoxyPress documentation is a bit redundant, not expressive enough (as your example shows), and may get out of sync with the implementation. Documenting parameter directions may play a bigger role in case of other languages that lack these additional constructs in function signatures.
I'm writing a C++/CLI extension, and am having issues getting the typing to work out. I'd appreciate your help and hope that I'm making a simple mistake with casting or passing parameters.
Firstly, here is the definition of the unmanaged function I'm trying to call (and which I can't change):
int getResponse(const RequestObject& requestObj, ResponseObject& responseObj);
Second, my unmanaged C++ RequestObject has a definition like so (which I also can't change):
class RequestObject
{
public:
RequestObject();
void addElement(int value, int age);
}
Now, in my managed C++/CLI code (using the 'IJW' interop ability), I want to call into this function. You'll note that I have unmanagedClassInstance (which holds the method given by the above getResponse function definition), and ManagedRequestObject reqs (which is just the managed version of what I want to put into the RequestObject).
RequestObject* unRequest = new RequestObject();
// Here I'm taking things from a managed version of RequestObject and making
// the unmanaged instances:
for each (ManagedRequestObject^ req in reqs) {
unRequest->addElement(marshal_as<int>(req->getValue()),
marshal_as<int>(req->getAge()));
}
// Call into the unmanaged object to get the request processed:
ResponseObject* unResponse = new ResponseObject();
int result = unmanagedClassInstance->getResponse(unRequest, unResponse);
Can you please help me understand how to correctly pass unRequest and unResponse into the getResponse() function?
If you keep using pointers for your unmanaged objects (which you might want to reconsiderate), you should be able to call the unmanaged function like this:
int result = unmanagedClassInstance->getResponse(*unRequest, *unResponse);
But unless strictly necessary, I'd suggest you do this instead:
RequestObject unRequest;
// Here I'm taking things from a managed version of RequestObject and making
// the unmanaged instances:
for each (ManagedRequestObject^ req in reqs) {
unRequest.addElement(marshal_as<int>(req->getValue()),
marshal_as<int>(req->getAge()));
}
// Call into the unmanaged object to get the request processed:
ResponseObject unResponse;
int result = unmanagedClassInstance->getResponse(unRequest, unResponse);
I am trying to write a small library which will use DirectShow. This library is to be utilised by a .NET application so I thought it would be best to write it in C++/CLI.
I am having trouble with this line however:
HRESULT hr = CoCreateInstance( CLSID_FilterGraph,
NULL,
CLSCTX_INPROC_SERVER,
IID_IGraphBuilder,
(void**)(&graphBuilder) ); //error C2440:
Where graphBuilder is declared:
public ref class VideoPlayer
{
public:
VideoPlayer();
void Load(String^ filename);
IGraphBuilder* graphBuilder;
};
If I am understanding this page correctly, I can use */& as usual to denote 'native' pointers to unmanaged memory in my C++/CLI library; ^ is used to denote a pointer to a managed object. However, this code produces:
error C2440: 'type cast' : cannot convert from 'cli::interior_ptr' to 'void **'
The error suggests that graphBuilder is considered to be a 'cli::interior_ptr<Type>'. That is a pointer/handle to managed memory, isn't it? But it is a pure native pointer. I am not trying to pass the pointer to a method expecting a handle or vice versa - I simply want to store it in my managed class) If so, how do I say graphBuilder is to be a 'traditional' pointer?
(This question is similar but the answer, to use a pin_ptr, I do not see helping me, as it cannot be a member of my class)
The error message is a bit cryptic, but the compiler is trying to remind you that you cannot pass a pointer to a member of a managed class to unmanaged code. That cannot work by design, disaster strikes when the garbage collector kicks in while the function is executing and moves the managed object. Invalidating the pointer to the member in the process and causing the native code to spray bytes into the gc heap at the wrong address.
The workaround is simple, just declare a local variable and pass a pointer to it instead. Variables on the stack can't be moved. Like this:
void init() {
IGraphBuilder* builder; // Local variable, okay to pass its address
HRESULT hr = CoCreateInstance(CLSID_FilterGraph,
NULL,
CLSCTX_INPROC_SERVER,
IID_IGraphBuilder,
(void**)(&builder) );
if (SUCCEEDED(hr)) {
graphBuilder = builder;
// etc...
}
}
I want to return from IDL an array of interfaces.
I try this:
interface ISecurityPolicy : IDispatch{
[id(6)] HRESULT GetPolicyList([out, ref, retval] SAFEARRAY(IEntityPolicy*)* result);
}
I get this warning(in VS 2010):
Warning 1 warning MIDL2456: SAFEARRAY(interface pointer) doesn't work using midl generated proxy : [ Parameter 'result' of Procedure 'GetPolicyList' ( Interface 'ISecurityPolicy' ) ]
Is this a bogus warning as http://social.msdn.microsoft.com/Forums/en-US/vcmfcatl/thread/84a632a9-4e29-4a95-8da7-f7aedb650339 might suggest ?
Declaring this as:
interface ISecurityPolicy : IDispatch{
[id(6)] HRESULT GetPolicyList([out, ref, retval] SAFEARRAY(IUnknown*)* result);
}
simplifies things a little for implementation of the interface.
It could still be a better idea though instead of returning an array of interfaces to the caller to return it an iterator over the "collection".
I guess this will be simple for C++/CLI gurus.
I am creating a wrapper which will expose high-performance C++ native classes to C# WinForms application.
Everything went fine with simple known objects and I could wrap also a callback function to delegate. But now I am a bit confused.
The native C++ class has a following method:
int GetProperty(int propId, void* propInOut)
At first I thought I could use void* as IntPtr, but then I found out that I need to access it from C#. So I thought about a wrapper method:
int GetProperty(int propId, Object^ propInOut)
but as I looked through the C++ source, I found out that the method needs to modify the objects. So obviously I need:
int GetProperty(int propId, Object^% propInOut)
Now I cannot pass Objects to native methods so I need to know how to treat them in the wrapper. As the caller should always know what kind of data he/she is passing/receiving, I declared a wrapper:
int GetProperty(int propId, int dataType, Object^% propInOut)
I guess, I can use it to pass reference and value types, for example, an int like this:
Object count = 100; // yeah, I know boxing is bad but this will not be real-time call anyway
myWrapper.GetProperty(Registry.PROP_SMTH, DATA_TYPE_INT, ref count);
I just added a bunch of dataType constants for all the data types I need:
DATA_TYPE_INT, DATA_TYPE_FLOAT, DATA_TYPE_STRING, DATA_TYPE_DESCRIPTOR, DATA_TYPE_BYTE_ARRAY
(DATA_TYPE_DESCRIPTOR is a simple struct with two fields: int Id and wstring Description - this type will be wrapped too, so I guess marshaling will be simple copying data back and forth; all the native strings are Unicode).
Now, the question is - how to implement the wrapper method for all these 5 types?
When I can just cast Object^% to something (is int, float safe to do that?) and pass to native method, when do I need to use pin_ptr and when I need some more complex marshaling to native and back?
int GetProperty(int propId, int dataType, Object^% propInOut)
{
if(dataType == DATA_TYPE_INT)
{
int* marshaledPropInOut = ???
int result = nativeObject->GetProperty(propId, (void*)marshaledPropInOut);
// need to do anything more?
return result;
}
else
if(dataType == DATA_TYPE_FLOAT)
{
float* marshaledPropInOut = ???
int result = nativeObject->GetProperty(propId, (void*)marshaledPropInOut);
// need to do anything more ?
return result;
}
else
if(dataType == DATA_TYPE_STRING)
{
// will pin_ptr be needed or it is enough with the tracking reference in the declaration?
// the pointers won't get stored anywhere in C++ later so I don't need AllocHGlobal
int result = nativeObject->GetProperty(propId, (void*)marshaledPropInOut);
// need to do anything more?
return result;
}
else
if(dataType == DATA_TYPE_BYTE_ARRAY)
{
// need to convert form managed byte[] to native char[] and back;
// user has already allocated byte[] so I can get the size of array somehow
return result;
}
else
if(dataType == DATA_TYPE_DESCRIPTOR)
{
// I guess I'll have to do a dumb copying between native and managed struct,
// the only problem is pinning of the string again before passing to the native
return result;
}
return -1;
}
P.S. Maybe there is a more elegant solution for wrapping this void* method with many possible datatypes?
It doesn't necessarily make sense to equate a C# object to a void*. There isn't any way to marshal arbitrary data. Even with an object, C# still knows what type it is underneath, and for marshaling to take place -- meaning a conversion from the C++ world to C# or vice-versa -- the type of data needs to be known. A void* is just a pointer to memory of a completely unknown type, so how would you convert it to an object, where the type has to be known?
If you have a limited number of types as you describe that could be passed in from the C# world, it is best to make several overloads in your C++/CLI code, each of which took one of those types, and then you can pin the type passed in (if necessary), convert it to a void*, pass that to your C++ function that takes a void*, and then marshal back as appropriate for the type.
You could implement a case statement as you listed, but then what do you do if you can't handle the type that was passed in? The person calling the function from C# has no way to know what types are acceptable and the compiler can't help you figure out that you did something wrong.