Suppose you have an automation object that needs to implement a callback into caller Visual Basic environment, which can be Scripting Host, Visual Basic for Applications, ASP etc. With all the late binding in VB scripting and so much different C++ code – how to put everything together? There are great choices, let us have three.<\/p>\n
On all three samples we add numbers on the way:<\/p>\n
300<\/code> is the initial argument of the VB caller<\/li>\n20<\/code> more in the VB callback<\/li>\n1<\/code> adds the C++ COM class<\/li>\n<\/ul>\nThe three .VBS<\/code> files will output 321<\/code> is everything goes well. The C++ method name is OuterDo<\/code>, while the supposed callback method is InnerDo<\/code>.<\/p>\nThere are two basic problems on the way:<\/p>\n
\n- We have to somehow pass the callback to COM class<\/li>\n
- We have to define function in a way that all they are compatible one with another<\/li>\n<\/ol>\n
Callback in VB Class Function<\/h3>\n
Straightforwardly, we can pass VB class to have a method called back. While it might be a good idea with VBA where it might be possible to add a reference to type library and have the named callback interface available in scripting environment (VB’s Implements<\/code> keyword), this does not work directly in VB Scripting Host. To work this around in .VBS sample we don’t reference IFirstSite<\/code> interface, and the automation object First<\/code> will access the method by its hardcoded name.<\/p>\nThe source code has commented parts which can be used to connect the parts more strictly using IFirstSite<\/code> interface.<\/p>\nClass FirstSite \n 'Implements IFirstSite\n Public Function IFirstSite_InnerDo(ByVal A)\n IFirstSite_InnerDo = 20 + A\n End Function\nEnd Class\n\nDim First\nSet First = WScript.CreateObject(\"AlaxInfo.VbsCallback.First\")\nResult = First.OuterDo(300, new FirstSite)\nWScript.Echo Result\n<\/code><\/pre>\nC++ implementation accepts the call using IDL syntax:<\/p>\n
interface IFirst : IDispatch\n{\n \/\/[id(1)] HRESULT OuterDo([in] LONG nA, [in] IFirstSite* pSite, [out, retval] LONG* pnB);\n [id(1)] HRESULT OuterDo([in] LONG nA, [in] IDispatch* pSite, [out, retval] LONG* pnB);\n};\n<\/code><\/pre>\nIn C++ we receive a COM interface of the class, and now we are to locate the callback method by its name using IDispatchEx<\/code> interface. Once we succeed with this, we invoke a dispatch interface call.<\/p>\nCallback in VB Function<\/h3>\n
An alternate option is to pass separate function IDispatch<\/code> interface and have it called from C++. compared to using strictly defined interface IFirstSite<\/code> this might look like an inferior way, however considering the workarounds we have to put in method above to stay compatible with Scripting Host, this method might look even a bit simpler.<\/p>\nFunction InnerDo(ByVal A)\n InnerDo = 20 + A\nEnd Function\n\nDim Second\nSet Second = WScript.CreateObject(\"AlaxInfo.VbsCallback.Second\")\nResult = Second.OuterDo(300, GetRef(\"InnerDo\"))\nWScript.Echo Result\n<\/code><\/pre>\nOn the caller side, the key to success is GetRef<\/code> method that creates a IDispatch<\/code>-enabled object from a separate function. C++ will use IDispatch::Invoke<\/code> on DISPID<\/code> of zero in order for the call to reach the implementation.<\/p>\nCallback through Connection Points<\/h3>\n
Connection points are standard and well known mechanism to deliver outgoing calls from an automation object, however they are subject to certain constraints:<\/p>\n
\n- late binding is taking place and we have to use
IDispatch::Invoke<\/code> to deliver calls, luckily Visual Studio is capable of generating proxy classes for that (no IFirstSite<\/code>-like strictly defined and callable interfaces!)<\/li>\n- connection points assume that there might be several parties connected to the points\/events, and the interface should nicely supports this (no return values!)<\/li>\n<\/ul>\n
Most of the environments have support for connection points on caller side, so this methods is nicely applicable.<\/p>\n
Sub Third_InnerDo(ByRef C)\n C = C + 20\nEnd Sub\n\nDim Third\nSet Third = WScript.CreateObject(\"AlaxInfo.VbsCallback.Third\", \"Third_\")\nResult = Third.OuterDo(300)\nWScript.Echo Result\n<\/code><\/pre>\nIn C++ there is a proxy class to deliver the event, so implementation is as simple as this:<\/p>\n
\/\/ IThird\n STDMETHOD(OuterDo)(LONG nA, LONG* pnB) throw()\n {\n ATLASSERT(pnB);\n CComVariant vB(nA + 1);\n ATLVERIFY(SUCCEEDED(Fire_InnerDo(&vB)));\n ATLASSERT(vB.vt == VT_I4);\n *pnB = vB.lVal;\n return S_OK;\n }\n<\/code><\/pre>\nNote that [out]<\/code> parameters need to be VARIANT<\/code>s or otherwise the returned values might get lost on the way.<\/p>\n<\/p>\n
So we are ready for a test run:<\/p>\n
D:\\Projects\\Alax.Info\\Repository-Public\\Utilities\\VbsCallback\\Scripts>cscript First.vbs\nMicrosoft (R) Windows Script Host Version 5.8\nCopyright (C) Microsoft Corporation. All rights reserved.\n\n321\n\nD:\\Projects\\Alax.Info\\Repository-Public\\Utilities\\VbsCallback\\Scripts>cscript Second.vbs\nMicrosoft (R) Windows Script Host Version 5.8\nCopyright (C) Microsoft Corporation. All rights reserved.\n\n321\n\nD:\\Projects\\Alax.Info\\Repository-Public\\Utilities\\VbsCallback\\Scripts>cscript Third.vbs\nMicrosoft (R) Windows Script Host Version 5.8\nCopyright (C) Microsoft Corporation. All rights reserved.\n\n321\n<\/code><\/pre>\nGood news, all three methods work well!<\/p>\n
Visual C++ .NET 2010 source code [Trac<\/a>, Subversion<\/a>] is available from SVN. .VBS<\/code> scripts are included<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"Suppose you have an automation object that needs to implement a callback into caller Visual Basic environment, which can be Scripting Host, Visual Basic for Applications, ASP etc. With all the late binding in VB scripting and so much different C++ code – how to put everything together? There are great choices, let us have… <\/p>\n