View Single Post
Posts: n/a
Default 04-18-2007, 11:00 PM

To answer the core question first: No I haven't done enough testing to confirm that the use of a loop inside a doTogether block always, or almost always results in an error. I've had this problem hit me in enough different ways, however, that my best guess is:

(1) The doTogether block really isn't key to the problem, although it does make it more likely to occur, since there are more threads running that can go wrong, and .

(2) What's really scary is that I think an error is not necessarily always going to occur when, for example, you're using a while event and a mouse/keyboard action to turn a method on and off. If the various indices used by the method are stable when the action occurs - something that can often occur if there is only a short loop in a method with other long blocks of code (or pauses) - I don't think you'll get an error.

By the way, I don't think the indexed loop is the only thing that gives problems - at least I've also had trouble using poses this way, and there are some comments about them, which I've never really understood, in the bug list.

But again, I'm guessing. (I too would like a roadmap.) What I've been doing since I saw the problem with the walk code is to make sure (as best I can - often it's trial and error) that whenever I want to stop a method with an event, I do it so I know what state things stop in. (This seems like a good idea in general, regardless of the source problem.)

As I indicated earlier, I'll generally just use the while event to control a Boolean variable and then use that to actually start and stop the method(s) at a clearly defined point. I think the very fast, absolute stop one gets from using the while event is what causes the problem of things being left in an undefined state - hence the solution is to avoid that if at all possible - while still keeping the real time control the while event does allow.
Reply With Quote