-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for the new data option supported by event generate (Tk 8.5) #47655
Comments
Follows a patch that adds support for the new data option supported This patch is only intended to correctly support tcl objects, trying to E.g.: import Tkinter
def handle_it(event):
print event.data.something
root = Tkinter.Tk()
root.something = {1: 2}
root.after(1, lambda: root.event_generate('<<Test>>', data=root))
root.bind('<<Test>>', handle_it)
root.mainloop() |
Actually, it could be the "detail" field too according to New patch added. |
Hello, I read the proposed patch "event_generate__data2.diff" and the Tcl/Tk manual http://www.tcl.tk/man/tcl8.5/TkCmd/bind.htm#M24
e.detail = d
e.user_data = d My reasoning is that the Tcl/Tk manual mentions the two names "detail" and "user_data". However, "user_data" may often be preferred because it has a clear meaning, whereas "detail" is quite vague.
Best regards, O.C. |
According to the Tcl/Tk docs the 'data' field is a string (i.e., for any user data) and the 'detail' field contains some internal data (so shouldn't be messed with); see http://www.tcl.tk/man/tcl8.5/TkCmd/event.htm#M16 Anyway, I hope you add a data field for user created virtual events. |
I don't agree with this comment.
This information comes form the documentation I cited, http://www.tcl.tk/man/tcl8.5/TkCmd/bind.htm#M24 :
From the document cited in msg165234 (http://www.tcl.tk/man/tcl8.5/TkCmd/event.htm#M16), my understanding is:
So, from the point of view of the guy who receives the event, the "%d" field can EITHER be a "detail" string like "NotifyAncestor" if event was "Enter"/"Leave"/"FocusIn"/"FocusOut" OR a "user_data" string in the case of a virtual event. It seems sensible that the Python interface provides both names. As a consequence, I think the patch should read: + # value passed to the data option is not a widget, take it I hope I understood the doc correctly. |
I have a patched Python 3.5.3 running mostly following |
Fill free to create a pull request. It may need tests and documentation though. |
So I pulled, but it seems the CLA is stuck somewhere. Investigating... |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: