Generally it will process it after wards. but lets say it recieves three things to display in a textbox all at once, but sent out are these:
"1"
"2"
"3"
when you put the debugger on you see it in order, but when it finishes processing in the textbox/etc you will see it in the order backwards more or less, generally what would be displayed is
"3"
"2"
"1"
This only happens when the coding is sent quicker. Can anyone tell why? I found this out when the NPC was attacking before entering the room, generally when I put the debugger on, you'd see the enter room message being first, then the attacks, but since it was all together, it ended up attacking first then you'd see him enter the room.
What it seems like more or less it processes the last thing it gets first.. Not sure what to do.
Last edited by Valleriani; Jan 9th, 2007 at 01:28 AM.
Re: Help with VB6 Network coding! Doesn't go in correct order!
Also if someone has sample coding that allows correct sending of data,
I can't understand why it displays the last coding it recieves first before the rest (GEnerally if they all got there at the same time)
Re: Help with VB6 Network coding! Doesn't go in correct order!
VB Code:
Public Sub Ostats(ByVal Index As Integer)
If frmServer.WStcpServer(Index).State <> sckClosed Then
MsgSend = "~g" & "Welcome to Future Galaxy! There are ~w" & usersonline & "~g users connected and a total of ~w" & userstotal & "~g connections today."
Generally the CharacterWelcome goes first. It will call ostats though. Generally CaracaterRoomA is where it sends more data, it sends this after getting some quick data:
VB Code:
If firstchar = 1 Then
If frmServer.WStcpServer(Index).State <> sckClosed Then
MsgSend = "~w<~g" & roomtitle(userroom(Index)) & "~w> " & roomdescription(userroom(Index)) & " " & Charsinroom & " is here with you. There is a " & LCase(itemsinroom) & " here."
What happens there is it sends the room data right after the Ostats to the player that joins.
Oh, and WinsockSend is how it sends it:
VB Code:
Public Function WinsockSend(pSock As Winsock, ByVal Data As String) As Boolean
' send the data on the passed winsock
If pSock.State = sckConnected Then
' send the data and return true
pSock.SendData Data & packetDelimiter
DoEvents
WinsockSend = True
Else
' return false because we're not connected
WinsockSend = False
End If
End Function
The packetdelim is 'packetDelimiter = Chr$(0)'
---
This is what it looks like in a text box (SAMPLE) on connect:
Welcome to Future Galaxy! There are 1 users connected and a total of 1 connections today.
<Dark Room> You are in a dark room. You can see faint light coming from a door to the south.
But sometimes it will do this, this is for any data, but this is a sample. Again this would be on connect.
<Dark Room> You are in a dark room. You can see faint light coming from a door to the south.
Welcome to Future Galaxy! There are 1 users connected and a total of 1 connections today.
As you see it will basicly jump around depending if it was sent to quickly. I don't lose any data, but it seems like its placing the last data recieved on first if two data are send together quickly.
P.S. Ignore the ~w, ~g, etc. Those are for color sending.
Re: Help with VB6 Network coding! Doesn't go in correct order!
This happens with any coding, but thats a sample. Generally whats happening is if two coding is sent out at the same time, the last one is displayed first. It should display the FIRST one always and go down the list.
Re: Help with VB6 Network coding! Doesn't go in correct order!
This might help.
It isn't perfect but it does address a lot of the common mistakes people make in TCP Winsock control programs. In particular it addresses "the packet fallacy" common to a lot of TCP programs. Remember, a TCP application does NOT have some sort of "packet" interface to the wire, it's a stream. That's the whole point of TCP! You are reading and writing streams, NOT packets.
This sort of "leet speak" leads a lot of programmers astray.
Re: Help with VB6 Network coding! Doesn't go in correct order!
In the first post sBuffer was a single Static String that was serving for all connections. This flaw was made much worse by the use of DoEvents() in the DataArrival event handler of course, but was a problem nonetheless.
The sample code in the ZIP archive I posted corrects this without changing the "style" of the program's buffer handling too much. It uses a String array of buffers, one per connection.
Do people realize what DoEvents() really does? I wonder. If so they'd be loathe to ever use it in Winsock control programs. A lot of programmers are already in a trance trying to cope with concurrency without adding this Joker to the deck. I suspect its presence is often a desperation measure when nothing else seems to work.
There are places for DoEvents(), but this just isn't one of them. Here it allows DataArrival for Connection 3 to be interrupted by DataArrival for Connection 7 (or whatever), and on and on, jamming everyone's input into the same sBuffer, etc. It can also lead to a stack overflow if you have several connections or a lot of data arriving. DoEvents() isn't a pause (or much of one). It simply calls the Form's Windows Message Loop once and then gives up its processor slice, like doing a Sleep(0) call, and then returns the oprn Forms count (which most people discard, calling it as if it were a Sub instead of a Function).
If studying the sample didn't help enough perhaps this explanation will shed a little more light.
Reply With Quote
Originally Posted by Valleriani
