a regular COM object. This removes the overhead induces by creating the full
ActiveX host environment. However, you would need to speak directly with the
Brian,
Thanks for the quick reply. I am guilty of hiding some of the details
in my first post. I am using an Eltima ActiveX control. It allows
one to capture the physical serial port, assign a virtual serial port
to the application of interest, and in this way inspect the serial
traffic (and perhaps even modify it). To be honest, I don't know
exactly how it works, nor do I necessarily want to. I simply want to
use it. I could probably program something up myself with the
SerialPort class or something else, but that would be a sidetrack. In
fact I think it would be a rather large sidetrack. The software from
Eltima includes not just the ActiveX control but serveral device
drivers that must be installed.
Incidentally, I don't have source code for the ActiveX control; just
the control itself.
Cheers,
Andrew
On Apr 12, 11:30 am, "Brian Muth" <bm...@mvps.org> wrote:
Let's step back a moment. You are finding that the ActiveX control seems
to
perform poorly.
What does the ActiveX control bring to the table? Why not use the
System.IO.Ports.SerialPort class which is designed for this purpose?
"Dave" <csharpu...@hotmail.com> wrote in message
news:663ca9c2-3cad-423f-b34a-fdd9d2ed630b@q15g2000yqj.googlegroups.com...
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- Hide quoted text -
- Show quoted text -