Use VB.net to manage a serial port for a VB6 application...

[Matthew Ryan via .NET 247]

I have a fairly large heritage VB 6 application that controlsabout 5 serial port devices with a fairly complicated but lineartimer scheme to service all of them (a work around of the singlethread aspect). I am trying to upgrade incrementally, and wantto write a VB.net stand alone class / module / application thatcan service one of these devices on it's own. I'd start thisapplication from the VB6 heritage program and (ideally) serviceinterrup ts that come from the new VB.NET application. Thatapplication would be controlling the serial port by itself. Does anyone have suggestions for the best way of implementingthi s? (Console, form, service, other?)

Thanks in advance,
Matt

-----------------------
Posted by a user from .NET 247 (http://www.dotnet247.com/)

<Id>OyPHY9nHW0q Nevr6S0z5Kw==</Id>

[Cor Ligthert]

Hi Matthew,

Almost the same answer as the question above this, did you already look in
the resource kit however now at the sample "How to Using the Comm Port"

I hope this helps?

Cor

http://msdn.microsoft.com/vbasic/vbrkit/default.aspx

And if you have problems installing it

http://msdn.microsoft.com/vbasic/vbr...q/#installvdir

[Dick Grier]

Hi,

That application would be controlling the serial port by itself. Does
anyone have suggestions for the best way of implementing this? (Console,
form, service, other?)
<<

Personally, I almost always create a Windows Forms client application for
this. In almost all cases, I want to be able to view results (even if only
for debugging and problem solving, where the application normally is
minimized), and for purposes of configuration to meet changing hardware
schemes. So, I'd vote for forms.

A single class for each device makes sense. In that way you can add or
delete hardware without having to change any program structure.

I never use Console applications for this sort of thing.

As to a Service -- well, there are reasons to create a service (then I'd
have the Windows Forms application as a support tool, but it need not run
unless called for). Debugging services are a little more tricky than
standard apps, and you tend to use a lot of logging that might otherwise
simply be displayed. Still, they have their place and shouldn't be rejected
"out of hand."

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.