Skipping Events in Multiple Events Structures

[Austin Lee]

Hi I am relatively new to Labview (about a month of training) and I created a project that allows you to play Tic Tac Toe against an AI for practice. The VI itself works fine and you can play games properly in succession  My problem is that when the main level VI reaches the second event structure in the Idle>Turn Handler Case Structure the player turn case wont register to start a new game because it is waiting for an event from the enums. I am looking for a practical way of skipping this because if I add a new event in the second event structure it runs the new game case on start up as well.

 

Any help with the project in general is welcome as well as style tips because I am learning.

 

I'm hoping that somebody can provide me with some insight into my project.

 

Thanks,

Austin

TicTacToe.zip

[hooovahh]

The solution is to architect the VI to only use one event structure.  There is no need to poll in the timeout case of the first event structure, just handle all events the user can perform (like Panel Close  ) in the one event structure and enqueue any states needed to handle the event.  Another side effect of your code is I can't press new game, if a game is still going on.  Again having one event structure handle everything the user can do is the way to go.

 

Not sure how many pointers you are looking for but here are a few:

 

The User Logon screen doesn't need the FP.Open or FP.Close (and then won't need the sequence structure) because the VI is configured to open when called, and close when done.

 

If you want the logon screen to be seen first, why is this not the top level VI and then have it call the UI that the user plays with?

 

The Logon screen doesn't allow the user to close, and I couldn't find a way to stop it other then the abort button.

 

The Main screen doesn't allow the user to close.  There is a button but using the normal close is more standard for users unfamiliar with your program.

 

Get rid of the toolbar for the logon screen.  There are tons of items in there that are just LabVIEW specific.  Only show the toolbar if you have a custom toolbar with items for your program.

 

Use more states in your QMH.  You have alot of code in the Idle case (with the event structure).  It helps to more easily follow the code if there are multiple states to call so they can be reused.  You could have a state called "Draw UI" which can be called on startup, and every time the user or AI moves.

 

Your sub VI's have error terminals in locations not seen often.  This isn't bad exactly but error wires are usually on the bottom right and bottom left terminals.  This borders on the line of style guide or preference not sure which.

 

Control labels being on the right is a preference thing but I think looks nicer.

 

You have some wires on top of other wires and going in the same direction.  This makes it very difficult to know exactly where a wire is connected without have to triple click it.

 

I saw some silver controls.  As I've mentioned before I don't have them but it should be consistent. The ones I saw were the error wires by the way.  I also saw some classic error controls.

 

You are using the Value Signal property node but I don't see where the event is handling the value change.  If you just want to change the value use a local variable.  Or at least use the Value property.  Value Signal indicates you are firing an event for a reason.

 

Unneeded coercion dots.  A coercion dot isn't necessarily a bad thing, but they can be so avoid them by giving the correct data type or perform an explicit conversion to the right type, knowing the possible consequences.

 

That being said, you have nice labels, code description, and I like the tab solution for the UI.  You are doing well for someone with a month of LabVIEW experience.

Edited February 7, 2013 by hooovahh

[Austin Lee]

Thanks I appreciate the feedback and I understand where you are coming from now that I have looked it over.

 

Control labels being on the right is a preference thing but I think looks nicer.

 

 

are you saying to label like this?

 

 

 

[todd]

I agree with hooovahh (including the "doing well" statement.

 

In addition:

 

Avoid duplicating code. In both VIs, there are case statements where both True and False cases write a string to a terminal (or its local). Move the terminal outide the case. I know it's a little thing, but being careful about it now will avoid trouble later. This also applies to creating two "This VI" references, and closing both.

Turn off labels for VIs that are obvious, and turn on labels for constants (instead of free labels) like row and column in the event structure.

Speaking of the event structure, you could turn those nine cases into one if you present the enums in a cluster, and use cluster-to-array for a 1d solution. Or use a cluster of 9 pic rings for the display, and convert it to enums in the code.

Edited February 7, 2013 by todd

[Austin Lee]

Speaking of the event structure, you could turn those nine cases into one if you present the enums in a cluster, and use cluster-to-array for a 1d solution. Or use a cluster of 9 pic rings for the display, and convert it to enums in the code.

 

Oh I now understand how I could easily apply this to the Enum Displays updating. Also, I could use the oldval of the "X" enum in the event structure to check the validity of the moves and the newval to update the display. Thats a very helpful trick. If I combine this with more states instead of SubVIs then I could use local variables to reference the values of the enums instead.

 

Thanks!

[hooovahh]

are you saying to label like this?

 

Sorry I wasn't more clear.  What I meant I put labels on the side of controls (right or left).  An easy way to see what I mean is to activate quick drop (CTRL + Space) and then use Move Terminal Labels (press CTRL + T) when on the block diagram.

Edited February 7, 2013 by hooovahh

[todd]

If I combine this with more states instead of SubVIs then I could use local variables to reference the values of the enums instead.

Or keep the enum values in a shift register. Ooh, you could log and play back games, then, Or "undo" and "redo" moves.