You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add support for the new data option supported by event generate (Tk 8.5) #47655
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:
assignee=Noneclosed_at=Nonecreated_at=<Date2008-07-18.12:52:45.025>labels= ['type-feature', 'expert-tkinter']
title='Add support for the new data option supported by event generate (Tk 8.5)'updated_at=<Date2018-05-29.14:18:00.977>user='https://bugs.python.org/gpolo'
Follows a patch that adds support for the new data option supported
event generate. It allows virtual events to pass a tcl object.
This patch is only intended to correctly support tcl objects, trying to
pass other objects (like a dict) will result in None being returned. If
you want to correctly pass and receive a dict, make it an attribute of
the tcl object being passed.
Could you please also add a field "e.user_data" ? This would simply be a copy of 'd' :
---
e.detail=de.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.
I did not understand why you try to get a widget reference from the "%d" field. Is it supposed to contain a widget name at some point ? According to the manual (and if I understood it well), it should never.
Best regards,
O.C.
mark-summerfield commented on Jul 11, 2012
mark-summerfieldmannequin
Mannequin
More actions
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.
dghjfrdj commented on Jul 11, 2012
dghjfrdjmannequin
Mannequin
More actions
I don't agree with this comment.
The 'detail' field also contains a string, one of the following: "NotifyAncestor", "NotifyNonlinearVirtual",...
When an event is received, the 'detail' and 'user_data' fields are de facto mixed up. Indeed, the "%d" field contains "the detail or user_data field from the event".
The "%d" field contains "the detail or user_data field from the event".
They are both strings:
"the %d is replaced by a string identifying the detail"
"For virtual events, the string will be whatever value is stored in the user_data field when the event was created (typically with event generate), or the empty string if the field is NULL"
For virtual events, the "data" string parameter given to "event generate" will be stored in the "user_data field" for the event. This string will then be available from the event through the "%d" substitution.
For events "Enter", "Leave", "FocusIn" and "FocusOut", the "detail" field will store a string among "NotifyAncestor", etc. This string will then be available from the event through the "%d" substitution.
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
+ # as the detail field
+ e.data = None
+ e.detail = d
+ e.user_data = d
I hope I understood the doc correctly.
Reacted by James E. A.
mkiever commented on Apr 22, 2018
mkievermannequin
Mannequin
More actions
I have a patched Python 3.5.3 running mostly following
the comments by O.C. If no one else is active on this
I can try to prepare something for submission.
Activity
gpolo commentedon Jul 18, 2008
Follows a patch that adds support for the new data option supported
event generate. It allows virtual events to pass a tcl object.
This patch is only intended to correctly support tcl objects, trying to
pass other objects (like a dict) will result in None being returned. If
you want to correctly pass and receive a dict, make it an attribute of
the tcl object being passed.
E.g.:
gpolo commentedon Jul 19, 2008
Actually, it could be the "detail" field too according to
http://www.tcl.tk/man/tcl8.5/TkCmd/bind.htm#M24
And this field may not exist, so I'm checking for that now.
New patch added.
dghjfrdj commentedon Jan 31, 2011
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
---
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.
mark-summerfield commentedon Jul 11, 2012
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.
dghjfrdj commentedon Jul 11, 2012
I don't agree with this comment.
The 'detail' field also contains a string, one of the following: "NotifyAncestor", "NotifyNonlinearVirtual",...
When an event is received, the 'detail' and 'user_data' fields are de facto mixed up. Indeed, the "%d" field contains "the detail or user_data field from the event".
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:
For virtual events, the "data" string parameter given to "event generate" will be stored in the "user_data field" for the event. This string will then be available from the event through the "%d" substitution.
For events "Enter", "Leave", "FocusIn" and "FocusOut", the "detail" field will store a string among "NotifyAncestor", etc. This string will then be available from the event through the "%d" substitution.
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
+ # as the detail field
+ e.data = None
+ e.detail = d
+ e.user_data = d
I hope I understood the doc correctly.
mkiever commentedon Apr 22, 2018
I have a patched Python 3.5.3 running mostly following
the comments by O.C. If no one else is active on this
I can try to prepare something for submission.
serhiy-storchaka commentedon Apr 22, 2018
Fill free to create a pull request. It may need tests and documentation though.
mkiever commentedon May 29, 2018
So I pulled, but it seems the CLA is stuck somewhere. Investigating...
ZelphirKaltstahl commentedon Nov 15, 2025
Any updates on this?
gh-47655: Add support for user data and detail of Tk events to tkinter (
pythongh-47655: Add support for user data and detail of Tk events to …
pythongh-47655: Add support for user data and detail of Tk events to …