NOTE: These instructions assume your modules are initialised and have registered their components and communication interfaces. The WinGate Module Wizard does this for you.
When your UI component is ready to start, the UI Host (WinGate Management Console) calls your ComponentEntry.Start function. In this function you call CommsConnect to initiate a connection to an Engine-side component. e.g.
When the Engine receives this request it looks for a registered ComponentCommunicationsInterface interface for the specified UUID (MY_COMPONENT_ENGINE_UUID). If found, it calls the ComponentCommunicationsInterface.CommsAccept function for that component. The CommsAccept function is where your Engine component can decide whether to accept the connection or not.
Notice in the example code above that we have the line
This is just an example of storing the connection associated with an connection peer and our example is assuming you have an std::map called connections of UUIDs to void *. The reason we use a container is because an engine component might have more than one UI component connected to it, typically when there are multiple WinGate Management Consoles connected to the same WinGate engine. By saving these connections you can send data to multiple WMCs at the same time. This is typically how configuration changes are propogated.
If your Engine module accepts the connection (By returning true) then WinGate informs the WMC which then calls your module's ConnectedComponentCommunicationsInterface.CommsConnected function. Your UI module then typically saves the connection somewhere for use later.
NOTE: You should be prepared to handle multiple incoming connections from different WinGate Engines, even though at present only one is possible.
Once ConnectedComponentCommunicationsInterface.CommsConnected has been processed, both modules are now able to send messages between each other.