#3002 bind<ButtonRelease-1> doesnt have same behavior on windows

[Don Porter]

Copied over from
http://sf.net/tracker/?func=detail&aid=3565164&group_id=10894&atid=110894
see that ticket for the attachment.

I write a xml layout feature for my work, recently. And I want bind a radiobutton or checkbutton click event on a method, but do not affect "command" configure option.
so I use the Events and Bindings, I write it like this widget.bind("<ButtonRelease-1>", lambda event: self.enable_toggle(data))
and
def enable_toggle(self, widget):
print widget_value_map[widget].get() # this will get the widget's variable and get it value.

on linux platform, the <ButtonRelease-1> event will be called after variable change, so I get the correct value in enable_toggle
but on windows platform, the event will be called before variable change, so I get the wrong value.

version:(python version 2.7.3)
Linux:
>>> Tkinter.TkVersion
8.5
>>> Tkinter.TclVersion
8.5
Windows:
>>> Tkinter.TkVersion
8.5
>>> Tkinter.TclVersion
8.5

I wrte a simple code(attachment) to show this bug. I want the code have same result on linux and windows, but it doesnt.

BTW: Is there a way to bind multiple method to an button click event? If a better one please tell me. Thank you. mailto: zy.netsec@gmail.com

[Donal K. Fellows]

I don't know for sure (not being a Win developer) but I think the problem relates to how Win native buttons handle events. Which is a bummer, because that's very hard to fix.

More detail:

I think it's probably linked to just when the button decides to fire. Classic Unix buttons (and radiobuttons and checkbuttons) do it when the <ButtonRelease-1> event hits an armed button, and they process the event in their class binding (i.e., after the widget-specific bindings). But this bug report provides evidence that Win native *buttons work differently. I didn't even know that they did that, but if it is true then it's hard to change. It's even possible that the platform guidelines call for checkbuttons/radiobuttons to change on <ButtonPress-1> events; if that's the case (don't know if it is) your plan won't work at all.

In short, I'm not at all sure what we could (or should) do about it. Saving the value on <ButtonPress-1> might be easier (you can just store it in case a subsequent <ButtonRelease-1> happens over the widget). Mind you, coding with GUI events remains tricky because they're fairly asynchronous and can be mixed up in order a lot. And I guess I'm not being very helpful. :-(