SerialPort.Write - is it alwasy blocking?

[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

 

[Peter Duniho]

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?

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

 

[Marcel Overweel]

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

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

regards,
Marcel

 

[Dick Grier]

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.

 

[Ben Voigt [C++ MVP]]

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?

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