busy problem with games programs

[Andy]

i'm starting to get the hang of these yahoo programs, but say i have 10 ids logged into a room, it seems that the program is always processing the dataarrival event which causes the hour glass cursor to show up. While its busy its kinda locks up the program and slows things down.. so my question is: is there a way to turn off the dataarrival event when its not needed?

[halcy0nical]

'note capturedata is a global boolean value set to true when user connects ids

Private Sub winsock_dataarrival(index as integer, byval bytestotal as long)
If capturedata = true then
<YOUR CODE HERE FOR CAPTURING>
Endif
End Sub

'to turn off data arrival, make a button click event, or case in dataarrival to set capturedata to false

[Andy]

cool i'll try that, thanks mike

[pascal]

I suggest ya to add some thread new generation used in that c#

[Mark__C]

vb6 cant be multithreaded stabily

[baloney_mahoney]

Originally posted by Mark__C
vb6 cant be multithreaded stabily

Well, not like C or C++ but you can do something to cause same affect

[new-us3r]

:/

[Mark__C]

Originally posted by baloney_mahoney
Well, not like C or C++ but you can do something to cause same affect

What do you mean?

[baloney_mahoney]

It's simple.

There are two ways to create a thread like action with VB.

1) Create a DDE client/server.

The server creates a new client for each pair of players. The
client contains two ms winsock controls, one for each player.

This approach works best but you need an understanding of
DDE.

2) Use an array of forms.

Here you have a main form which loads a new form for each
pair of players. Again, the forms contain two ms winsock controls.
Basically, it works the same as the DDE approach except all forms
are running as a single application.

I have used both approaches and both work fine.

[Mark__C]

Which pair of players are you talking about?

[baloney_mahoney]

Silent Master posted something about 10 IDs logged into a room.

pascal posted something about using a thread.

You posted vb6 cant be multithreaded.

I'm simply saying that VB can simulate multithreaded by having two of the 10 IDs be assigned to a single DDE client or to a form.

So, if you have 10 IDs then you will have 5 DDE clients or 5 forms each handling two of the IDs or players.

Example: Suppose I wanted to make a booster (for me it would be a chess booster). Let's say I wanted to make one that could handle xx number of players. I dont want to bogle up the VB program by having one module handle all the players so I would create a DDE server. The server takes the 1st two players and assigns them to the 1st DDE client, takes the 2nd pair of players and assign them to a 2nd DDE client, etc, etc.

In essense, each DDE client acts like a thread.

Thats all.

[Mark__C]

well i never worked with dde, but good to know

[baloney_mahoney]

Unfortunately, VB6 doesnt offer much help in the DDE developement. But once you know it, it is a very powerful way
of designing thread-like applications.

But if you dont want to get into DDE just try doing the multi-form method. It works just a well but has it's limitations on number of form threads running under same application. After so many VB will start to boggle down. That's why I reccomend DDE

[Mark__C]

You said different forms run on different threads? You sure about this?

[baloney_mahoney]

I didnt say that different forms run on different threads. I said that it simulates a thread-like occurance.

All a thread is, is a code string running on it's own. So, if you have a VB program that starts a form from an array then that form runs on it's own as long as there is something that causes that form code to take action such as a socket recieving data from a host.

Look at it this way. If you used one form with a 100 sockets on that form each socket act on it's own. But the code to handle this is quite complex and it will bogle up the application. So, if you use multiple forms with only two sockets on each then the whole VB applcication runs much better.

The only reason for doing this is so that if you write a VB program that handles, say, 100 IDs, then you wont have all 100 IDs being processed by a single form. The end results of using multiple forms is very much the same as multi-threading as in Java or C++.

The best way is still to use DDE. That way all forms are running as a seperate thread.

[Mark__C]

That is wrong. VB is Apartment threaded. It can run
many threads in its one MTA (multi-threaded apartment) and can create
as many STAs (single-threaded apartments) as it needs. Because all
threads in the apartment rely on TLS (thread local storage), they have
what is called thread-affinity. Because of this, they must be serialized
so that they can't step all over each other. This means each thread
runs in turn and only when a sub call (or something else that makes the
thread give up its timeslice like DoEvents) is completed can context
switch to another thread. This is why using DoEvents inside of tight
loops allows the system to do other things in your app (like refresh the
screen). This is also why DoEvents can allow a sub to become reentrant
(it can be executed a second time before the first time completes).
There is no simple way to make the threads in a single instance of VB
behave asynchronously (although with a timer and careful use of
DoEvents and making sure subs are protected from reentrancy, you can
simulate it).

Thats the response I got after requesting more info on this at a vbforum

[baloney_mahoney]

Good grief man! Since you were the one that ask the question about VB and treading it was appearant that you didnt know about alot about VB-threading. I just gave you or anyone with little knowledge of this a simple approach to creating the same affect without getting into all that bumble jumbo you picked up somewhere else.

If you want to create a multithreaded VB application using what you picked up at another forum then do so.

But what I told you works and it is the simpliest way to create threading in VB. I have written many VB applications using the
method I told you and it works perfectly. And yes, you always use DoEvents. I didnt mention it because I wasnt going into detail and DoEvents is a given; everyone knows that you need to use it.

Reentrancy has nothing to do with multi-threading. You can have reentrancy if you want to have a thread do a call-back to the main thread. Once a thread is put into motion it's one it's own until it either closes itself or the main thread closes it. You don't enter a thread more than once, you simply create another thread and let it run. This is how Java, a truely OOP and multi-threaded language works.

If you use DDE then you do not need DoEvents (except within the client's own execution) because DDE is simply the running of two or more fully operational independent applications under control of the server application.

[Mark__C]

lol ok

"I just gave you or anyone with little knowledge of this a simple approach to creating the same affect without getting into all that bumble jumbo you picked up somewhere else. "

Im just telling you what I read on from a PRO VB Programmer... you will not have the same effect with your method it is not asynchronous..


"If you want to create a multithreaded VB application using what you picked up at another forum then do so."

Thanks for the permission :)

"But what I told you works and it is the simpliest way to create threading in VB. I have written many VB applications using the
method I told you and it works perfectly. And yes, you always use DoEvents. I didnt mention it because I wasnt going into detail and DoEvents is a given; everyone knows that you need to use it. "

Once again, from what I was told by the other guy, your method does not work...

"Reentrancy has nothing to do with multi-threading. You can have reentrancy if you want to have a thread do a call-back to the main thread. Once a thread is put into motion it's one it's own until it either closes itself or the main thread closes it. You don't enter a thread more than once, you simply create another thread and let it run. This is how Java, a truely OOP and multi-threaded language works."


From http://embedded.com

By carefully controlling how data is shared, we create reentrant functions, those that allow multiple concurrent invocations that do not interfere with each other. The word pure is sometimes used interchangeably with reentrant.


Sounds like it has alot to do with multithreading.. :O No you dont enter a thread more than once you have different threads invoking the same sub/function..


No I doubt u need DoEvents on DDE.. Doevents in one app wont affect the other ones thread.. whats your point?

[baloney_mahoney]

OK. case closed