Hopefully someone helps you, but if you want to increase the odds, you need to get straight to the point as concisely as possible. As it stands, this question is going to get a large proportion of tl;dr sentiment, which will limit the number of qualified people who can provide a good answer. (sorry, we're really lazy)
–
Kirk WollOct 4 '12 at 1:45

5

Without reading all that code, but based on the description: don't rely on comparing images - you should split your "model" of game state from the way it is drawn.
–
John3136Oct 4 '12 at 1:49

1 Answer
1

As you discovered, comparing Images directly is not the answer. I haven't tested this, but I suspect it's because each Image could have very different properties, despite being loaded from the same resource. For example, if one button was only 20-pixels square, and another was 50, the Height and Width properties would be different. See the documentation for some other properties.

A better way to handle this, as @John3136 said, is to split the model away from the drawing. This could be as simple as using the Tag property on each button to store either an "O" or an "X". You'd check everything the same as you do now, except you'd be comparing b1.Tag == b2.Tag && b2.Tag == b3.Tag. A better, but more complicated way, would be to have an array of something to represent your game board. As with any programming problem, there's many possible ways to do it - char[9] would be the simplest, although string[] or bool?[] could work, creating an enum and storing an array of that, or an array of arrays of any of the above. (Also List<> instead of an array, eventually). In either case, you'd have to update your model at the same time as you update the image, but you're then doing a much simpler comparison to test for victory.

You're entirely correct about disabling the buttons - but here's a question for you. What happens if someone clicks on a button that the other player has already clicked? Sure, you can alert the user, but it still looks like a valid choice. Why not disable it as soon as it's clicked?

I'm also going to go a bit further afield and give you a tip for the "//Excluded rest of code (just button clicks, repeats of same for 9 squares)" line. If you're going to repeat the same code more than twice (and some people would say more than once), you're better off making a function which takes whatever will differentiate it as an argument. For example, you could have

This isn't doing anything you don't already know how to do - you're already calling other functions, and passing buttons around in arguments (see winCheck()). It's just a way of thinking which will reduce the amount of code you need to write, and thus the places you need to fix any given bug.

Ah. I didn't think to check tags. That actually worked well. I'd like to thank you for the detailed help and for reminding me I should function the multiple lines. I'd also like to thank Kirk and John for their help as well in formatting and idea. I really appreciate it guys. This program now works as far as I can tell.
–
AlteisenOct 4 '12 at 3:06

I love Tags. I store all kinds of things in there. They're easy to over-use, and can make your code impossible to follow if you abuse them, but they're great for anything that has a one-to-one relationship with controls. Good luck with the rest of your class!
–
BobsonOct 4 '12 at 3:17