self modifying buttons - memory game
I assume there is probably a better way to do this. The code is functional but its really slow if you have a large amount of buttons. http://www.nabble.com/file/8220/gui.py gui.py -- View this message in context: http://www.nabble.com/self-modifying-buttons---memory-game-tf3693914.html#a1... Sent from the Python - tkinter-discuss mailing list archive at Nabble.com.
On Fri, May 04, 2007 at 01:09:08PM -0700, RickB wrote: . . .
I assume there is probably a better way to do this. The code is functional but its really slow if you have a large amount of buttons. http://www.nabble.com/file/8220/gui.py gui.py . . . I suspect you are indeed working too hard.
When I execute the "gui.py" source, I see a 6 x 5 grid of buttons. They all appear active, but there are no random color changes evident, as I suspect you intended. What's the effect you're after? My guess is that we can help you achieve it far more economically. I've scanned the source, but I don't get the point.
Cameron Laird-2 wrote:
On Fri, May 04, 2007 at 01:09:08PM -0700, RickB wrote: . . .
I assume there is probably a better way to do this. The code is functional but its really slow if you have a large amount of buttons. http://www.nabble.com/file/8220/gui.py gui.py . . . I suspect you are indeed working too hard.
When I execute the "gui.py" source, I see a 6 x 5 grid of buttons. They all appear active, but there are no random color changes evident, as I suspect you intended. What's the effect you're after? My guess is that we can help you achieve it far more economically. I've scanned the source, but I don't get the point. _______________________________________________ Tkinter-discuss mailing list Tkinter-discuss@python.org http://mail.python.org/mailman/listinfo/tkinter-discuss
I edited the original message. I don't know how this mailing list stuff works or if you guys got the edit or what. I am viewing it through nabble.com. I posted a new file in my edit: http://www.nabble.com/file/8227/gui2.py It is just a version of a memory game where you have a grid of cards and you have to pick a matching pair. If you click the one of buttons in the grid you will see a color. You then must click a button with a matching color. If you do both those buttons will stay that color. If your second pick does not match, both buttons turn back to gray. I think my new file is pretty efficient and functional. Thanks for the interest anyway, Rick -- View this message in context: http://www.nabble.com/self-modifying-buttons---memory-game-tf3693914.html#a1... Sent from the Python - tkinter-discuss mailing list archive at Nabble.com.
On Mon, May 28, 2007 at 01:46:25PM -0700, RickB wrote:
. . .
I assume there is probably a better way to do this. The code is functional
. . . http://www.nabble.com/file/8227/gui2.py It is just a version of a memory game where you have a grid of cards and you have to pick a matching pair. If you click the one of buttons in the grid you will see a color. You then must click a button with a matching color. If you do both those buttons will stay that color. If your second pick does not match, both buttons turn back to gray. I think my new file is pretty efficient and functional. . . . Ah! I have the new version, and it does indeed entertain me, and appear to be correct. While we're here, I'll make a couple of comments: A. I'd likely replace col[z]=c[col[z]%5] with col[z] = c[col[z] % len(c)] B. You can replace col = [] for z in range(w*h): col.append(z) with col = range(w * h) C. I think what you're *really* after, though, is # Make copies of the color list to # fill out the whole grid, then col = (c * (1 + t / len(c)))[:t] # shuffle the colors. random.shuffle(col) D. Similarly, there are ways to recode maker() so that it's briefer, easier to understand, and less tricky in its global manipulation. E. There are choices for c, w, and h that leave the "board" unplayable--that is, all pairs have been matched, and all that's left are unpaired colors.
Nice work!
Thanks for the interest and the comments. I didn't have the time or motivation to try to make it work with arbitrary sizes. I had to turn it in for a class. I don't know if its in the version I posted, but the version I handed in had an initial set of buttons where you could select one of three pre-determined sizes. Thanks again, Rick Cameron Laird-2 wrote:
On Mon, May 28, 2007 at 01:46:25PM -0700, RickB wrote:
. . .
I assume there is probably a better way to do this. The code is functional
. . . http://www.nabble.com/file/8227/gui2.py It is just a version of a memory game where you have a grid of cards and you have to pick a matching pair. If you click the one of buttons in the grid you will see a color. You then must click a button with a matching color. If you do both those buttons will stay that color. If your second pick does not match, both buttons turn back to gray. I think my new file is pretty efficient and functional. . . . Ah! I have the new version, and it does indeed entertain me, and appear to be correct. While we're here, I'll make a couple of comments: A. I'd likely replace col[z]=c[col[z]%5] with
col[z] = c[col[z] % len(c)] B. You can replace col = [] for z in range(w*h): col.append(z) with col = range(w * h) C. I think what you're *really* after, though, is # Make copies of the color list to # fill out the whole grid, then col = (c * (1 + t / len(c)))[:t] # shuffle the colors. random.shuffle(col) D. Similarly, there are ways to recode maker() so that it's briefer, easier to understand, and less tricky in its global manipulation. E. There are choices for c, w, and h that leave the "board" unplayable--that is, all pairs have been matched, and all that's left are unpaired colors.
Nice work! _______________________________________________ Tkinter-discuss mailing list Tkinter-discuss@python.org http://mail.python.org/mailman/listinfo/tkinter-discuss
-- View this message in context: http://www.nabble.com/self-modifying-buttons---memory-game-tf3693914.html#a1... Sent from the Python - tkinter-discuss mailing list archive at Nabble.com.
On Wed, May 30, 2007 at 06:32:56AM -0700, RickB wrote: . . .
Thanks for the interest and the comments. I didn't have the time or motivation to try to make it work with arbitrary sizes. I had to turn it in for a class. I don't know if its in the version I posted, but the version I handed in had an initial set of buttons where you could select one of three pre-determined sizes. Thanks again, . . . You're welcome. I'll add that there's deep value in delivering something that "passes", that is, meets the grader's or other client's requirements. Congratulations, and good luck with any other Tkinter-ing you do!
The Checkbutton widget Var = IntVar() Checkbutton(Frm, text = "Destroy", variable = Var) wants Var to be an IntVar, but it also works if Var is a StringVar and you set() Var to "0" and "1". Is there a possibility that this will be "fixed" some time in the future, or would it be safe to keep Var as a StringVar, or is it not even really broken (I don't know Tcl/ Tk which I assume is allowing this?)? In my case it would be nice to keep "0" or "1" in a MySQL database column and have a Tkinter form with a Checkbutton do the right thing without having to change the column to an int, or keep converting back and forth between chars and ints for that one column to keep from running into trouble in the future. Thanks! Bob
On Tue, 28 Aug 2007 13:30:02 -0600 Bob Greschke <bob@passcal.nmt.edu> wrote:
The Checkbutton widget
Var = IntVar() Checkbutton(Frm, text = "Destroy", variable = Var)
wants Var to be an IntVar, but it also works if Var is a StringVar and you set() Var to "0" and "1". Is there a possibility that this will be "fixed" some time in the future, or would it be safe to keep Var as a StringVar, or is it not even really broken (I don't know Tcl/ Tk which I assume is allowing this?)? In my case it would be nice to keep "0" or "1" in a MySQL database column and have a Tkinter form with a Checkbutton do the right thing without having to change the column to an int, or keep converting back and forth between chars and ints for that one column to keep from running into trouble in the future.
Hi Bob, I am not a tcler myself, but I think the integers are being converted to strings anyway when they are passed to tcl, so 1 and "1" might be equivalent here. If you want to be even more safe, you might want to use the checkbutton's onvalue and offvalue options, like onvalue="1", offvalue="0" . Michael
On Tue, 28 Aug 2007 13:30:02 -0600 Bob Greschke <bob@passcal.nmt.edu> wrote:
The Checkbutton widget
Var = IntVar() Checkbutton(Frm, text = "Destroy", variable = Var)
wants Var to be an IntVar, but it also works if Var is a StringVar and you set() Var to "0" and "1". Is there a possibility that this will be "fixed" some time in the future, or would it be safe to keep Var as a StringVar, or is it not even really broken (I don't know Tcl/ Tk which I assume is allowing this?)? In my case it would be nice to keep "0" or "1" in a MySQL database column and have a Tkinter form with a Checkbutton do the right thing without having to change the column to an int, or keep converting back and forth between chars and ints for that one column to keep from running into trouble in the future.
On Aug 29, 2007, at 02:37, Michael Lange wrote: Hi Bob,
I am not a tcler myself, but I think the integers are being converted to strings anyway when they are passed to tcl, so 1 and "1" might be equivalent here. If you want to be even more safe, you might want to use the checkbutton's onvalue and offvalue options, like onvalue="1", offvalue="0" .
onvalue?! offvalue??!! Every time I look in Grayson's Python and Tkinter programming I DON'T see something. :) I never even knew those existed and I must have looked at that section 100 times over the years. Thanks! Bob
participants (4)
-
Bob Greschke -
Cameron Laird -
Michael Lange -
RickB