On 17 Sep 2007 12:11:10 -0700, "christian"
"christian" <chri...@myvisionexpress.com> escribió en el mensaje
news:46eed14e$1@forums-1-dub...
"Jim O'Neil [Sybase]" <jon...@sybase.com> wrote in message
news:vrmte3t2lkn8bg5ts...@4ax.com...
For a "write only" solution you can get by with fileopen, filewrite,
fileclose and use the applet in the control panel to set port parameters.
This "could" work for read also, but read will generally throw characters
away if the application does not keep up with the import data and will hang
on receive if no data is present and flow control allows the open to
complete.
You can find several OCX controls that will allow a reasonsable serial
interface or write your own c/c++ dll that has spawns a thread to read from
the port to fill a buffer and PB calls to read from the buffer. There are
also easy calls to set port parameters and flow control. Examine the
signals etc.
In the same vane, I suspect that it would be easy to use some of the .net
framework calls and deploy as a winform.
"Vipul" <sp...@myvisionexpress.com> wrote in message
news:480cd91f@forums-1-dub...
Tyler Cruse wrote:
> Well, the normal fileread and filewrite work, but have some real
> limitations. First, they work differently for different hardware. So,
> what works for COM1 with on motherboard UART may or may not work with
> smart ports (DigiBoard, EdgePort, USB based port cables, etc).
I have used FileRead with the EdgePort, but on XP and not on Vista. on
XP, though, it works well.
> For a "write only" solution you can get by with fileopen, filewrite,
> fileclose and use the applet in the control panel to set port
> parameters. This "could" work for read also, but read will generally
> throw characters away if the application does not keep up with the
> import data and will hang on receive if no data is present and flow
> control allows the open to complete.
I'm working on a wrapper for this. The wrapper spawns a thread that
polls the port for data. A 100 millisecond polling interval seems to be
working well and my implementation doesn't experience any data loss. The
only thing keeping me from posting this on CodeXchange or as a PBDJ
article is that it crashes if you destroy the object in the middle of a
poll. (You can stop the polling, then destroy the object with no problems.)
> You can find several OCX controls that will allow a reasonsable serial
> interface or write your own c/c++ dll that has spawns a thread to read
> from the port to fill a buffer and PB calls to read from the buffer.
> There are also easy calls to set port parameters and flow control.
> Examine the signals etc.
>
> In the same vane, I suspect that it would be easy to use some of the
> .net framework calls and deploy as a winform.
I haven't looked very deeply, yet, but at a first glance, I didn't see
any framework components for communicating with an RS232 port. If
someone else finds something, please let me know. I'd like to move from
Win32 API to .NET if I could.
which is coming from System.IO.Ports.SerialPort.
Regards
Jason 'Bug' Fenter [TeamSybase] pisze: