Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsVB SyntaxEnterprise DevelopmentDatabase AccessControlsCOMWin APICrystal ReportDeploymentGeneralGeneral 2
Related Topics
VB.NET / ASP.NETMS SQL ServerMS AccessOther Database ProductsMore Topics ...

VB Forum / General / August 2004



Tip: Looking for answers? Try searching our database.

Ending a Winsock_DataArrival event

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Jerry Spence1 - 31 Aug 2004 00:50 GMT
I have a Winsock1_DataArrival Event
----------------------
Private Sub WinSock1_DataArrival(Index As Integer, ByVal bytesTotal As Long)

   A small bit of processing

       Call MyProcedure

End  Sub
-----------------------------
Sub MyProcedure

..Lots of work here

End Sub
-------------------------

My problem is that during the MyProcedure part I need to do a
Winsock1.SendData. However, as far as the Winsock component is concerned I
haven't actually ended the DataArrival routine (Because I am calling the
subroutine and it doesn't complete until the End Sub), and so it has no
effect. Any ideas how I could get round this?

-Jerry
Bob Butler - 31 Aug 2004 01:15 GMT
<cut>
> My problem is that during the MyProcedure part I need to do a
> Winsock1.SendData. However, as far as the Winsock component is
> concerned I haven't actually ended the DataArrival routine (Because I
> am calling the subroutine and it doesn't complete until the End Sub),
> and so it has no effect. Any ideas how I could get round this?

you can do a SendData under the conditions you describe... ar eyou getting
an error?   winsock controls often benefit greatly from DoEvents since
otherwise things tend to get buffered.  Have you tried that?

Signature

Reply to the group so all can participate
VB.Net... just say "No"

Jerry Spence1 - 31 Aug 2004 02:41 GMT
> you can do a SendData under the conditions you describe... ar eyou getting
> an error?   winsock controls often benefit greatly from DoEvents since
> otherwise things tend to get buffered.  Have you tried that?

Thanks Bob

That's a great hint about DoEvents, That did seem to help a lot.

However I need to do:

winsock1.SendData someData
winsock1.SendData somemoreData
winsock1.SendData evensomemoredata

How can I tell  if one has completed before sending the next?

-Jerry
Bob Butler - 31 Aug 2004 14:29 GMT
<cut>
> However I need to do:
>
[quoted text clipped - 3 lines]
>
> How can I tell  if one has completed before sending the next?

You can use the SendComplete event to set a flag but it sounds like you are
trying to force the tcp/ip protocol to be something it isn't.  It is a
streaming protocol meaning that all data sent is simply appended to any
previous data already sent and not yet delivered.  TCP/IP is designed in
such a way that it can combine or split packets that you send according to
various factors at any point along the route from sender to receiver.

standard practice is to add your own information to the data stream so that
the receiving end can break it up to match what was sent.  The 3 most common
options are:
1. always send fixed-length records
2. prefix each record with a fixed-length header that specifies the length
of the record to follow, it's type and/or any other info you need to pass
about it
3. follow each record with a delimiter that does not occur in the record
(vbNullChar or vbCRLF are common choices for text-based transmissions)

the receiving end pulls in the new data, appends it to a buffer and then
checks to see if one or more complete records has been received; if so they
are processed and removed from the start of the buffer.

Signature

Reply to the group so all can participate
VB.Net... just say "No"

 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.