question about converting Console App that uses ActiveX ctrl to ATL dll that uses ActiveX ctrl. Advice needed on Serial Port ActiveX Control

Hi,

My COM/ATL skills are quite rusty and I'm having trouble getting
started on a project I need to do for work. We have a third party
ActiveX ctrl that monitors serial port traffic. It allows you to
inspect incoming serial messages, possibly modify them, and send them
on their way. We also have an example console app that uses this
ActiveX control. I would like to use the ActiveX control inside a ATL
COM dll and have the GUI (and certain other parts) in a C# GUI or
possibly a C++ GUI (MFC or ATL). The idea would be to keep all the
handling of serial communcations in C++. In the Console App, they
have in their main() function something similar to:
hRes = AtlAdvise(...);

sps->ResetBus ();

while( GetMessage(&msg, NULL, 0, 0) && !IsExit )

{

  if (!TranslateAccelerator(msg.hwnd, NULL, &msg))

  {

    TranslateMessage(&msg);

    DispatchMessage(&msg);

  }

}

It's not clear to me how to transfer this logic to a ATL dll. The
AtlAdvise, I believe, sets up a connection between the "source" in the
ActiveX control, and the "sink", in the console app in this case. I
don't recall having to have a "TranslateMessage/DispatchMessage" in a
ATL dll. I am familiar (although my skills are rusty) with setting up
a ATL dll and creating objects that expose methods for clients to
call. I would still need to do this as I want clients to have the
abiltiy to call in for occasional updates. However, I also have this
ActiveX control that presumably monitors serial traffic and must be
setup.

Some specific questions are:

1) Can you point me to an example of using an ActiveX control from
within a ATL dll?

2) Will I still need the AtlAdvise and the TranslateMessage/
DispatchMessage logic?

3) I have the book ATL Internals (first edition) by Rector and Sells.
I don't see this topic discussed. Am I missing it?

If you have read this far, thank you. And if you're wondering, why
doesn't he simply use the ActiveX directly in a C# app, well, we tried
this, with limited success. The serial communications lagged and
performance was generally bad. We might try again, but our current
thoughts are that because of all the interop stuff, and our changing
(some) of the messages, the serial traffic was slowed down. The hope
is that by having all the serial communication and modification done
in a C++ (ATL) layer and just sending out the occasional event and
receiving the occasional method request from the GUI, we'll duplicate
the results of the Console app.

Thanks,

Dave