By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,152 Members | 1,837 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,152 IT Pros & Developers. It's quick & easy.

MSCommLib ActiveX Control in a C# Windows Service?

P: n/a
I'm working on a C# Windows Service that needs to monitor serial port
communication. Because the .Net framework does not include support for
serial communications, I've decided to use the Microsoft Communication
Control (MSCommLib) that comes with Visual Studio 6. It seems easy to use
and works well enough for me within the context of a Windows Application.
Because I need the serial ports to be monitored 24/7, however, a Windows
Service seems like the better choice.

Because the MSCommLib control is an OCX, it needs to be placed on a Form.
I've added a Form that presumably won't be displayed during runtime to my
Windows Service project. At this point, with just a Windows Service and an
Empty Form, I am able to install and start the service with no problems.
After adding the MSCommLib Control to the form, however, when I start the
service I get an error message that says something like:

"Your Service started and then stopped. Some services do this"

Placing Event Log debug statements in the code reveals that the Service
never appears to return from the Form.InitializeComponents() function, in
which the MACommLib control is instantiated and initialized.

Does anyonone have any advice regarding my situation? Perhaps I am trying
to do the impossible...Any workarounds or alternate solutions for monitoring
a server's serial ports would be greatly appreciated.

Thanks,

Will
Nov 15 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Will,

Generally speaking, trying to access UI elements is a bad idea when
running in the context of a service. Granted, you can have your service
interact with the desktop (by clicking "allow service to interact with
desktop"), but you can't guarantee that there will always be a desktop.

Because of this, you might want to conisder making calls to the Windows
API through the P/Invoke layer to access the serial port. There are a few
classes out there that do this already, and I believe there is an
implementation on gotdotnet.com.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Will" <de*@rusmo.com> wrote in message
news:cp********************@giganews.com...
I'm working on a C# Windows Service that needs to monitor serial port
communication. Because the .Net framework does not include support for
serial communications, I've decided to use the Microsoft Communication
Control (MSCommLib) that comes with Visual Studio 6. It seems easy to use and works well enough for me within the context of a Windows Application.
Because I need the serial ports to be monitored 24/7, however, a Windows
Service seems like the better choice.

Because the MSCommLib control is an OCX, it needs to be placed on a Form.
I've added a Form that presumably won't be displayed during runtime to my
Windows Service project. At this point, with just a Windows Service and an Empty Form, I am able to install and start the service with no problems.
After adding the MSCommLib Control to the form, however, when I start the
service I get an error message that says something like:

"Your Service started and then stopped. Some services do this"

Placing Event Log debug statements in the code reveals that the Service
never appears to return from the Form.InitializeComponents() function, in
which the MACommLib control is instantiated and initialized.

Does anyonone have any advice regarding my situation? Perhaps I am trying
to do the impossible...Any workarounds or alternate solutions for monitoring a server's serial ports would be greatly appreciated.

Thanks,

Will

Nov 15 '05 #2

P: n/a
Sam
You may want to try using NetSerialComm, it works well:
http://msdn.microsoft.com/msdnmag/is...netserialcomm/

Supposedly, MS is supposed to add serial ports to a future version of the
..NET framework. Anyone know if 2.0 will have this functionality?

"Will" <de*@rusmo.com> wrote in message
news:cp********************@giganews.com...
I'm working on a C# Windows Service that needs to monitor serial port
communication. Because the .Net framework does not include support for
serial communications, I've decided to use the Microsoft Communication
Control (MSCommLib) that comes with Visual Studio 6. It seems easy to use and works well enough for me within the context of a Windows Application.
Because I need the serial ports to be monitored 24/7, however, a Windows
Service seems like the better choice.

Because the MSCommLib control is an OCX, it needs to be placed on a Form.
I've added a Form that presumably won't be displayed during runtime to my
Windows Service project. At this point, with just a Windows Service and an Empty Form, I am able to install and start the service with no problems.
After adding the MSCommLib Control to the form, however, when I start the
service I get an error message that says something like:

"Your Service started and then stopped. Some services do this"

Placing Event Log debug statements in the code reveals that the Service
never appears to return from the Form.InitializeComponents() function, in
which the MACommLib control is instantiated and initialized.

Does anyonone have any advice regarding my situation? Perhaps I am trying
to do the impossible...Any workarounds or alternate solutions for monitoring a server's serial ports would be greatly appreciated.

Thanks,

Will

Nov 15 '05 #3

P: n/a
Hi Will,
Because the MSCommLib control is an OCX, it needs to be placed on a
Form.


This is not true, you do not have to place the MSComm control in a form.
Simply add a reference in your C# project to MSCommLib. Click on the COM
tab and browse to select your MSCOMM32.OCX .

Then create an instance of it in your C# class:

MSCommLib.MSComm mscomm = new MSCommLib.MSCommClass();

The MSComm control has been working fine for me however I am still looking
for a better .NET way to do it:

Some alternatives to using the MSComm control in .NET

C#
http://www.gotdotnet.com/Community/U...4-dfe325097c69

Managed C++
http://www.codeproject.com/managedcpp/howtocomport.asp

VB .NET
http://www.mentalis.org/classlib/class.php?id=15
http://www.gotdotnet.com/Community/U...0-93391fc4c196

C# ( This uses thread pooling that is not supported under Win98)
http://www.gotdotnet.com/Community/U...4-dfe325097c69

C#
http://www.gotdotnet.com/Community/U...f-0045b0c79ec7

-Ed
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 10/28/2003
Nov 15 '05 #4

P: n/a
> This is not true, you do not have to place the MSComm control in a
form. Simply add a reference in your C# project to MSCommLib. Click on the COM tab and browse to select your MSCOMM32.OCX . Then create an instance of it in your C# class: MSCommLib.MSComm mscomm = new MSCommLib.MSCommClass();


Ed, thanks a ton for the tip. I'm going to give this a shot first before I
punt on the MSCommLib control.

Will.
Nov 15 '05 #5

P: n/a
Thanks for the link...it'll serve as a backup plan if Ed Sutton's suggestion
doesn't work.

Thanks,
Will.
Nov 15 '05 #6

P: n/a
> Ed, thanks a ton for the tip. I'm going to give this a shot first
before I punt on the MSCommLib control.


I agree that is the least riskiest approach.

The MSComm control is very reliable. I am using it in my C# application to
reliably communicate at high speeds 460,800 bps using a USB/Serial
interface.

Whenever I get enough time though, I want to use a more .NET approach.

This guy says "MSCOMM is the most bug-free component that Microsoft has ever
released.". Actually, I think Microsoft purchased it from Sax.

http://www.vbrad.com/source/src_mscomm_tutorial.htm

-Ed
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 10/27/2003
Nov 15 '05 #7

P: n/a
Thanks Ed, your suggestion worked!
Nov 15 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.