Tab control only allows two page selections

[CoastalMaineBird]

I am obviously having a hard time getting away from the concept of variables driving my thought process.

Think of it this way: a wire is a variable.  It's true.  The wire coming OUT of a function is an ASSIGNMENT of that variable.  The wire going INTO a function is a READ of that variable. Once you've READ that variable the last time, IT DOESN'T EXIST any more!

The dataflow paradigm follows naturally from that idea.

I found out that the event requires the event to occur at least once when inside of a loop so I found the solution was to pull it out of the loop. 

--- I'm not sure what that means.  But event structures are simple: when you execute one, it means one thing only: WAIT until one of the configured events happens.

Period.

You can add as many event cases as you need to the structure, but the meaning is the same: WAIT until one of the configured events happens.

Usually they are used in a loop, because you want your program to handle a given event and then go wait for another one.

You don't have to use them that way, but that's the norm.

Usually you put code inside the event structure to handle each specific case, but you don't have to.

[RavensFan]

One other important point about event structures.  For normal static events such as Value Change, the event is automatically registered.

So if you hit a boolean button, then you do other stuff for a while, then you hit an event structure that has an event case to handle the value change on button, it will execute immediately based on the fact the event has already occurred.  It won't sit around waiting for the button change unless it hasn't occurred at all yet.

[llf264]

I think that I've made progress towards a more "data flow" type of program with this iteration.  Instead of leaving the user completely free to do whatever they want, whenever they want, then have a ton of coding to react to that, it does seem more efficient to guide the user along the path (as long as nothing is missing from the path that the user would otherwise need) to the final result.

It is a different way of thinking...  I was leary of adding loops for everything as I thought for every single loop in a program each loop would be eating up processor time and end up overloading the CPU.  But, with the right combination of event structures, event monitors look to be less needed than I otherwise would have thought and it still doesn't have every single loop continuously running.  Enless of course, I have swung too far in the other direction..

Code still has tons of problems, but represents a better data flow I think...  anyone see where I am running in the wrong direction on this version?

I know that my initialization routines still suck, but I'm getting better with those each day.

[aeastet]

The start cycle but loop inside of a loop is not a good idea. Did you give up on what I did for you? If you run the one that I gave you you will see that it does not take up much processor. If it did something was wrong with the program and needed to be fixed. Otherwise it should not have taken up much processor at all unless it was executing something.

[llf264]

Dear aeastet ... no.. I didn't give up on that, I was just reviewing your VI as a matter of fact trying to figure out how to document in my mind how to classify the main differences between the two styles why one is preferable to the other.  Your code looks so much more compact and efficient than what I did since Thr. 

I'm trying to see how I can move my ver 2 back towards what you are accomplishing in your vi.