[RESOLVED] DoEvents does not resume from its last position - why?

[T3mp0]

Update
My original question:

Please help me understand why, at some point, DoEvents does not resume from its last position (marked in the code below).
It will work a few times and then, after DoEvents, the code is not executed and is stuck at bProcessing()=True.

Cause of the problem:
Another DoEvents triggered _DataArrival from the same socket (as expected). However, it then got stuck in a loop because there was a missing condition that would allow DoEvents to exit from the procedure and go back to where it was interrupted and resume its work.

Solution:

If bProcessing(Index) Then Exit Sub

This is how (in a simplified form) looks my code. It's a server (using standard Winsock) that handles connections from a couple of connected clients (hence the Index to identify them):

Private Sub sckServer_DataArrival(Index As Integer, ByVal bytesTotal As Long)

    lBytes(Index) = bytesTotal ' Count received data for each client (Index)

    While lBytes(Index) > 0

        If bProcessing(Index) Then Exit Sub ' Required condition that allows the DoEvents to exit this procedure and resume its work from the last state

        If lBytes(Index) >= 65536 And bProcessing(Index) = False Then ' Let's say I'm expecting 64 kB of data (this is just an example)
            bProcessing(Index) = True
            Call HandleData(Index)
            bProcessing(Index) = False
        End If

        DoEvents

    Wend

End Sub

Sub HandleData(Index as Integer)

    sckServer(Index).GetData byteData, vbArray + vbByte, 65536: lBytes(si) = lBytes(si) - 65536
	
    For i=1 to nClients
        If i=nPairedClient Then
            sckServer(i).SendData {received data} ' Forward received data to the paired client
            DoEvents
            'This was the place when at some point DoEvents did not resume but thanks to the added condition in sckServer_DataArrival() now it does (read above)
        End If
    Next i
	
End Sub

[Eduardo-]

I don't think that putting a DoEvents in that async event is a good idea. Because as you have it now while it is processing a DataArrival it can come another DataArrival. And what happens? A mess.

[T3mp0]

No, that's why there is bProcessing(). The data should be arriving, I'm expecting it. I assure you it works as intended.

[baka]

use peekmessage. it gives u more control of what kind of incoming windows messages u want through.
usually what we want is to not freeze the mouse/keyboard/form.
a sleep 0/1 is also good to add so give system some air.

[Eduardo-]

No, that's why there is bProcessing(). The data should be arriving, I'm expecting it. I assure you it works as intended.

So when bProcessing is true and it receives another packet, it looses that packet because it is still processing another prior one...
If you don't experience that issue is because it does not happen, but something in the logic is not right...

[Elroy]

Is sckServer_DataArrival an event? If so, you're possibly recursing that event with the DoEvents in there. Event-driven programs don't need DoEvents, as the OS (i.e., Windows) will raise the event automatically when it's idling. If it's not idling, then your program is possibly processing the prior sckServer_DataArrival event, and shouldn't be interrupted.

That's the core philosophy of event-driven software, which basically all Windows programs are.

[T3mp0]

The first post is updated with the solution.