SerialPort.Write - is it alwasy blocking?

  • Thread starter Thread starter Marcel Overweel
  • Start date Start date
M

Marcel Overweel

Hi all,

I've noticed that SerialPort.Write() returns when all data has been sent.
But is also has a BytesToWrite property, so this wouldn't be logical.

So far, I've never seen any value other than 0 for that property.
Even with very large blocks, the Write call returns after all chars have
been transmitted. And thus, BytesToWrite is always 0.

Am I missing something here?

regards,
Marcel
 
Hi all,

I've noticed that SerialPort.Write() returns when all data has been sent.
But is also has a BytesToWrite property, so this wouldn't be logical.

So far, I've never seen any value other than 0 for that property.
Even with very large blocks, the Write call returns after all chars have
been transmitted. And thus, BytesToWrite is always 0.

Am I missing something here?
Click to expand...

From my limited experience with the SerialPort class, it seems to me as
though the class API is an amalgam of the original unmanaged API and an
attempt to provide a more .NET-like way to do things. There are things in
the SerialPort class that I can't see myself ever actually using.

Probably the biggest category there are these kinds of properties that
allow you to inspect the internal state of the SerialPort. To me, knowing
that state isn't important, but I suspect that there's code out there that
operates at a much less abstract level with certain kinds of hardware that
needs to know, thus the existence of features like that in the class.

I would say that unless you have code that is specifically timing
dependent on the data transmitted through the serial port hardware, you
can safely ignore that property. Or, put another way, if that property
were important to your code, you'd already know it. :)

Pete
 
Peter Duniho said:
From my limited experience with the SerialPort class, it seems to me as
though the class API is an amalgam of the original unmanaged API and an
attempt to provide a more .NET-like way to do things. There are things in
the SerialPort class that I can't see myself ever actually using.

Probably the biggest category there are these kinds of properties that
allow you to inspect the internal state of the SerialPort. To me, knowing
that state isn't important, but I suspect that there's code out there that
operates at a much less abstract level with certain kinds of hardware that
needs to know, thus the existence of features like that in the class.

I would say that unless you have code that is specifically timing
dependent on the data transmitted through the serial port hardware, you
can safely ignore that property. Or, put another way, if that property
were important to your code, you'd already know it. :)

Pete
Click to expand...

Thanks Pete,
it sure sounds like an animalgram or whatever you called it.
- what does that mean? :)

regards,
Marcel
 
The general answer is, "Yes" the .write method blocks -- at least, until all
data have been buffered by the serial port driver (there may be as many as
several hundred bytes yet unsent, but the driver has no way to be queried
for this information). Thus, in my experience, the .ByteToWrite method will
alway return 0.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.
 
Marcel Overweel said:
Hi all,

I've noticed that SerialPort.Write() returns when all data has been sent.
But is also has a BytesToWrite property, so this wouldn't be logical.

So far, I've never seen any value other than 0 for that property.
Even with very large blocks, the Write call returns after all chars have
been transmitted. And thus, BytesToWrite is always 0.

Am I missing something here?
Click to expand...

Is BaseStream.BeginWrite the missing link you're looking for?
 
Back
Top