HighTechTalks DotNet Forums  

SerialPort.Write - is it alwasy blocking?

Dotnet Framework microsoft.public.dotnet.framework


Discuss SerialPort.Write - is it alwasy blocking? in the Dotnet Framework forum.



Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old   
Marcel Overweel
 
Posts: n/a

Default SerialPort.Write - is it alwasy blocking? - 07-02-2009 , 02:44 AM






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

Reply With Quote
  #2  
Old   
Peter Duniho
 
Posts: n/a

Default Re: SerialPort.Write - is it alwasy blocking? - 07-02-2009 , 11:48 AM






On Thu, 02 Jul 2009 00:44:46 -0700, Marcel Overweel <moverweel (AT) gonen (DOT) nl>
wrote:

Quote:
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

Reply With Quote
  #3  
Old   
Marcel Overweel
 
Posts: n/a

Default Re: SerialPort.Write - is it alwasy blocking? - 07-03-2009 , 01:57 AM



"Peter Duniho" <no.peted.spam (AT) no (DOT) nwlink.spam.com> schreef in bericht
newsp.uwf8zcpjvmc1hu (AT) clampitt (DOT) ..
Quote:
On Thu, 02 Jul 2009 00:44:46 -0700, Marcel Overweel <moverweel (AT) gonen (DOT) nl
wrote:

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
Thanks Pete,
it sure sounds like an animalgram or whatever you called it.
- what does that mean?

regards,
Marcel

Reply With Quote
  #4  
Old   
Dick Grier
 
Posts: n/a

Default Re: SerialPort.Write - is it alwasy blocking? - 07-03-2009 , 11:12 AM



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.

Reply With Quote
  #5  
Old   
Ben Voigt [C++ MVP]
 
Posts: n/a

Default Re: SerialPort.Write - is it alwasy blocking? - 07-21-2009 , 02:52 PM



"Marcel Overweel" <moverweel (AT) gonen (DOT) nl> wrote

Quote:
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?

Quote:
regards,
Marcel


Reply With Quote
Reply




Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.