Wait until response?

[acrym]

Hi, I am making a turn-based card game application.

One feature is it allows you to use cards during your opponent's turn.

I need some way of pausing a subroutine, waiting for an opponent's response, and executing that response before finishing your subroutine.

I've already made a winsock control, and when your opponent responds it jumps to winsock_dataArrival. This is fine but I need some way of waiting for your opponent to send data again which tells when they are done responding. From there I would start the dataArrival routine over again and then execute their response.

Any thoughts on how to accomplish this? I've gotten suggestions on Do while loops but from my experience they always crash! Thanks!

[baja_yu]

Analyze the data that the opponent sent (and that you receive in dataArrival). 'Invent' a marker that will tell the other side that they completed. When you get that marker you can resume operation on the other side.

[acrym]

Ok, but what do I put in to pause that operation? A "Do while" loop maybe? If so how does that work? Do I have to put a marker like you said inside the loop? How do I do that without it crashing?

[vpben]

In visual basic 6 loops are EVIL, especially while using winsock. I would store received data in a buffer and process it later, after you receive your response. You are a lot better off stability and CPU use wise to just exit the routine and wait for the data.

[si_the_geek]

Agreed - what I would suggest is to have two separate routines rather than one.

[acrym]

vbpen - Thanks, but I need some way, after the data arrives, to enter the subroutine again? Because there will be code that needs to be executed in the middle of it?

si - I suppose if all else fails that could be the detour solution. But before I decide, is maybe a Do while loop possible? ( One idea I've heard of is to use DoEvents? ) If so how do I properly use it?

[Lenggries]

Are you sure you want to write this in VB6? This sort of problem is trivial in a multi-threaded program, but VB6 isn't multi-threaded. Any chance you can switch it to .net?

[acrym]

Lenggries - Possibly. I have it but is all my old code and forms compatible with Vb.Net?

Or can you just tell me if it is absolutely necessary for this to be multithreaded?

[si_the_geek]

multithreading would be "nice", but not important. The main significant change is that it would be easier to make sure that the screen updates at the same time as your code is doing something. In terms of this particular issue it would probably just be different code rather than less code.

Quite a bit of VB6 code is compatible with VB.Net (but not ideal), and forms are generally not. While "moving forward to 2002" with .Net is generally a good idea (it has more features, and is quicker to code), moving an existing project is not a great idea - it is better to switch when you start a new project.

si - I suppose if all else fails that could be the detour solution.

Unless you have the desire to spend extra time to achieve less, it shouldn't be an alternative solution, it should be your primary choice.

But before I decide, is maybe a Do while loop possible?

It is possible, but it is very wasteful.

That method uses CPU time for no reason whatsoever, and has no benefits - it just adds more work for you (more than the loop itself) to do the equivalent of what is going to happen fully automatically already.

VB is based on the idea of Events triggering code, so allow the event you are expecting to be the trigger, rather than having your code needlessly eat processor time to just wait until that same trigger happens.

( One idea I've heard of is to use DoEvents? ) If so how do I properly use it?

There are several things you need to bear in mind when using DoEvents.

The first is that if it is in a loop, it can easily use 100% CPU for the entire time the loop is running. That can be reduced to less than 10% by adding careful usage of the Sleep API etc, or it can be reduced to 0% by using event based code instead. Even if your situation needs extra variables etc to transfer data from one routine to the next, it will take less effort overall to use events.

The next is that as implied by the name DoEvents, it allows other events to happen. For example, the user could click on a card (and start the same routine again, so it is running twice, causing one 'copy' to have errors), or close the program. As such you need to ensure that all of the possible events are dealt with appropriately, which in simple terms could be disabling the form to stop the user clicking anything or using the keyboard to do something.

Another is that your program can be closed during a call to DoEvents (even if your forms are disabled), so after each DoEvents call you need to add code to ensure that the program can close safely. There is an explanation of how to do that in the FAQ article How should I close my form/program/class?

[acrym]

Thank you for the informative answer, si. I think I will try my hand at Vb.Net then.