SerialPort_ReceivedEvent splits data in parts

[DraguVaso]

Hi,

I'm having some troubles with my Serial-Port application:

It always splits the ReceivedData in different parts.
for exemple: I should receive "SIM PIN REQUIRED", but I receive iit in 3
different events: "SIM PI", "N REQUIR" and "ED". does anybody knows why this
happens? And how I can do something about this? Is it some setting fo the
comport? A buffer need to make larger?

thanks a lot in advance,

Pieter

[Dick Grier]

Hi,

This is normal (all communications work this way, not just serial). You can
never assume that a full message will be available when you want it -- you
must wait for it.

You have two options. Either add a delay BEFORE you attempt to input the
data, of sufficiently long duration to assure that the device will have
completed sending it to you, or... (BEST), simply append new data as it
arrives to a buffer. As soon as it all has arrived, you process it. You
may determine this by length or by content.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004.

[DraguVaso]

Thanks!
Well, I did it the second way, it seemd the best, fastest and most flexible
to me too.

Pieter

"Dick Grier" <di**************@msn.com> wrote in message
news:uR*************@TK2MSFTNGP15.phx.gbl...

Hi,

This is normal (all communications work this way, not just serial). You can never assume that a full message will be available when you want it -- you
must wait for it.

You have two options. Either add a delay BEFORE you attempt to input the
data, of sufficiently long duration to assure that the device will have
completed sending it to you, or... (BEST), simply append new data as it
arrives to a buffer. As soon as it all has arrived, you process it. You
may determine this by length or by content.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004.

[DraguVaso]

Thanks!
Well, I did it the second way, it seemd the best, fastest and most flexible
to me too.

Pieter

"Dick Grier" <di**************@msn.com> wrote in message
news:uR*************@TK2MSFTNGP15.phx.gbl...

Hi,

This is normal (all communications work this way, not just serial). You can never assume that a full message will be available when you want it -- you
must wait for it.

You have two options. Either add a delay BEFORE you attempt to input the
data, of sufficiently long duration to assure that the device will have
completed sending it to you, or... (BEST), simply append new data as it
arrives to a buffer. As soon as it all has arrived, you process it. You
may determine this by length or by content.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004.