LabVIEW
Sudoku
@mcsynth wrote:
jdebuhrThat was a great suggestion about being able to hide the clues. That way you can only use the clues when you really feel stuck. It only took a couple of minutes to implemented, and it puts some of the challange back into the game.Thanks,
McSynth
Hi Vahid!
Thanks! The front panel is very pretty and the code seems to work. Excellent! 🙂
Personally, I don't like the coding style: Way to many local variables and stacked sequences and way too much duplicate code (For example the inner stacked sequence with 9 frames has 9 identical frames operating on 9 explicit subsets. All this could be done in a FOR loop using one (instead of 9) instances of the same code. If you have time, try to polish the code a little bit. It should also fit on a single screen. Many of your while loop have a fixed number of iterations, thus they should be replaced by FOR loops. 😄
Thanks. Now you added a few more diagram comments for explanation.
This is exceptional code for a beginner LabVIEW programmer. Now you need to try to use some more advanced programming techniques to simplify and streamline the existing code. You seem to learn fast, so that should be fun. 🙂
Overall, the code is still 10x more complicated that it should be. For example, to see if a position is won, you do exceedingly complex sequences. Why do you represent the board sometimes as strings and sometimes as a numeric array? I would do all computations on the numeric and convert to/from a strings just for the UI (include range checking and validation). The board could even be an Xcontrol doing the conversion and validation and the main VI could be entirely numeric.
As a very simple example, here's some compact code that checks if a board is won. As you can see, you don't need to extract all sub arrays and then sequentially process them. You can do the extraction and processing at the same time, re-using the same code and reducing the amount of data in memory. Most of your while loops should be FOR loops, you can still terminate early using the conditional terminal, but you no longer need to check [i] at each iteration.
Your program is still way too sequential. You should try to embrace dataflow.
You can probably eliminate a lot of of case structures if you would make seperate event cases for each button.
I would probably place the solver code inside the event structure.
You should keep the board representations in shift registers and eliminate all local variables. It would make the code much more efficient and easier to edit and debug. Similarly, all hidden/invisible controls that only serve as locals should be eliminated. Normally there is no need to involve the front panel into computations unless it displays useful information for the user.
hi i am vahid
i download your code ( win code)
wowwwwww.......... your cod was veryyyyyyyyyyy interesting....that is right...our code is not proffesional...
i hope you send me your E mail ... i need your help .... i like labview very much but i don't have any one that be able too help me...
if you have any code that is usfull for me please send it for me...my E mail : VahidKhaki63@yahoo.com
many years ago i work whit Matlab ( i do not like write code) , but in labview we can do every thing..
Well, I wrote "millions" of programs, and most are probably not of interest to most. 😄
If you are looking for a game example, I just spend a few minutes polishing up my old 4x4 Tic-Tac-Toe. (no code change, just some cosmetics and code cleanup). It is now in LabVIEW 2009.
There is little documentation, though.
