Hallo, jkling@fridaythang.com hat gesagt: // jkling@fridaythang.com wrote:

So as I was saying, the 'next possible state transition' boxes seemt to lag behind the current state. By placing an extra [del 10] inlet to send each choice twice, this upates the next possible states correctly.

Just a note: What actually should be changed with my patch is the order, in which messages are triggered and their number. For this you should use [trigger] or [t ...] , and not [delay]. [del] may have a similar result in this case, but [del] should be used for timing things, not for ordering things.

However, it requires an initial message of '0' to [t b a] to initialize the rest of the state machine to the proper location on the list. Then, each subsequent choice can be made from the radio toggle.

This becomes problematic because I would like to use the next possible state transitions to display the voting choices. However, using the workaround of [del 10] to send the choice twice means that the display for the next possible state transition is actually changing twice (albiet very quickly). I can imagine another hack-ish workaround involving a toggle to allow or prevent the message being passed from the next possible state transition(s) to the display, but I'd rather not have to do that if it's not necessary.

Yep, the real solution should be a different triggering. The left part of the patch now does the choice by looking up an element in a list of choices by position. The choice is send to the right part, which looks up a new pair of possible choices and sends it back to the left part, using [list]'s cold inlet to just store the choice.

Displaying the choices also is done in the right part of the patch.

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__