Re: question about converting Console App that uses ActiveX ctrl to
ATL dll that uses ActiveX ctrl. Advice needed on Serial Port ActiveX Control
Brian,
Once again, thanks for the response. With the advantage of more
research and hindsite, I think I would simplfiy and rephase my
original posting to:
I would like to create an ATL inproc server that
1) acts as both a "sink" for events from a third party COM object
2) provides methods that can be called by clients (possibly from C++
clients, possibly from C# clients)
3) acts as a source and fires events when something exciting happens
(for example, when the ATL inproc server receives a particularly
important piece of information from the third party control, it should
fire an event for all interest clients).
A particular path would be the following:
1. Third party COM object fires event.
2. Received by ATL inproc server (using a sink?). Data stored in
memory of ATL inproc server.
3. ATL inproc server fires an event. (now our server is the source!)
4. Client catches event and calls in for extra info from Inproc Server
(using methods of interface).
I think all the information I gave about Serial communications simply
confuses the isses. I have not found many references about programming
an inproc server that is both a sink and a source. Presumabely there
are some threading issues to consider. For example, the sink of the
server will be storing some data it catches from the 3rd party
control. This data will also be accessed by clients. About the only
posting I saw on the whole topic is this:
http://www.generation-nt.com/us/atl-control-an-event-source-sink-help-90985=
42.html
You might recognize the author (Alexander Nickolov) as someone who was
quite active in this newsgroup back in the day. Anyhow, he advises
having the sink and source on seperate objects. I was thinking along
those lines. I was hoping to find an example that went into more
depth as to which threading model to choose and how best to protect
the data that is being gathered on the sink and made available (via
method calls) to clients, or perhaps even sent out as part of the
source events from the server.
Thanks again,
Dave
On Apr 12, 4:02 pm, "Brian Muth" <bm...@mvps.org> wrote:
I think it is very difficult to give advice regarding a 3rd party product
that we know nothing about, apart from the fact that it sounds like a
"heavy-weight" control.
With some ActiveX controls, you can sometimes use a subset of its feature=
s
if you don't actually want to see the GUI display, simply by treating it =
as
a regular COM object. This removes the overhead induces by creating the f=
ull
ActiveX host environment. However, you would need to speak directly with =
the
authors of the control to see if this is a reasonable approach.
Brian
"Dave" <csharpu...@hotmail.com> wrote in message
news:44b07ff9-efa7-4197-83ad-2ac29e5c4f32@r18g2000yqd.googlegroups.com...
Brian,
Thanks for the quick reply. I am guilty of hiding some of the detail=
s
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. I=
n
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 see=
ms
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 the=
m
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 th=
e
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 t=
he
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 u=
p
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 t=
his
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, wh=
y
doesn't he simply use the ActiveX directly in a C# app, well, we tri=
ed
this, with limited success. The serial communications lagged and
performance was generally bad. We might try again, but our curren=
t
thoughts are that because of all the interop stuff, and our changing
(some) of the messages, the serial traffic was slowed down. The h=
ope
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 duplicat=
e
the results of the Console app.
Thanks,
Dave- Hide quoted text -
- Show quoted text -- Hide quoted text -
- Show quoted text -