Game Development Reference
In-Depth Information
{
CComBSTR firstObjectNameProxy;
CComBSTR secondObjectNameProxy;
CComBSTR thirdObjectNameProxy;
HRESULT hr;
// Call the first test logic method
hr = toolLogic ->GetFirstAlertObjectName(&firstObjectNameProxy.m_str);
// Call the second test logic method
hr = toolLogic ->GetSecondAlertObjectName(&secondObjectNameProxy.m_str);
// Call the third test logic method
hr = toolLogic ->GetThirdAlertObjectName(&thirdObjectNameProxy.m_str);
_bstr_t firstObjectName = firstObjectNameProxy;
_bstr_t secondObjectName = secondObjectNameProxy;
_bstr_t thirdObjectName = thirdObjectNameProxy;
MessageBox(0, (char*)firstObjectName, “First Object”, 0);
MessageBox(0, (char*)secondObjectName, “Second Object”, 0);
MessageBox(0, (char*)thirdObjectName, “Third Object”, 0);
}
else
{
MessageBox(0, “Could not instantiate COM object”, “Error”, 0);
}
::CoUninitialize();
return S_OK;
}
Alternate Architecture Structure
An alternative to the proposed architecture is removing the remoting entry point
and placing it as a bridge between the specific tool logic and all other entry points.
Doing so would convert the architecture into something like a client and server
environment, storing a single copy of the specific tool logic on the server. The
clients would not require the tool logic, just an interface definition they can cast to
a Remoted proxy wrapper.
Search Nedrilad ::




Custom Search