This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Add support for the new data option supported by event generate (Tk 8.5)
Type: enhancement Stage: patch review
Components: Tkinter Versions: Python 3.4
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: alex.rodas, asvetlov, dghjfrdj, gpolo, mark, mkiever, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2008-07-18 12:52 by gpolo, last changed 2022-04-11 14:56 by admin.

File name Uploaded Description Edit
event_generate__data2.diff gpolo, 2008-07-19 15:33 review
Pull Requests
URL Status Linked Edit
PR 7142 open mkiever, 2018-05-27 17:09
Messages (8)
msg69951 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-07-18 12:52
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.


import Tkinter

def handle_it(event):

root = Tkinter.Tk()
root.something = {1: 2}
root.after(1, lambda: root.event_generate('<<Test>>', data=root))
root.bind('<<Test>>', handle_it)
msg70040 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-07-19 15:33
Actually, it could be the "detail" field too according to
And this field may not exist, so I'm checking for that now.

New patch added.
msg127658 - (view) Author: O.C. (dghjfrdj) Date: 2011-01-31 20:44

I read the proposed patch "event_generate__data2.diff" and the Tcl/Tk manual

* Could you please also add a field "e.user_data" ? This would simply be a copy of 'd' :
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.

* 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,

msg165234 - (view) Author: Mark Summerfield (mark) * Date: 2012-07-11 08:29
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

Anyway, I hope you add a data field for user created virtual events.
msg165254 - (view) Author: O.C. (dghjfrdj) Date: 2012-07-11 12:13
I don't agree with this comment.

1) The 'detail' field also contains a string, one of the following: "NotifyAncestor", "NotifyNonlinearVirtual",...

2) 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, :

* 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"

From the document cited in msg165234 (, 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
+       = None
+                e.detail = d
+                e.user_data = d

I hope I understood the doc correctly.
msg315621 - (view) Author: Matthias Kievernagel (mkiever) * Date: 2018-04-22 17:09
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.
msg315624 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-04-22 17:33
Fill free to create a pull request. It may need tests and documentation though.
msg318035 - (view) Author: Matthias Kievernagel (mkiever) * Date: 2018-05-29 14:18
So I pulled, but it seems the CLA is stuck somewhere. Investigating...
Date User Action Args
2022-04-11 14:56:36adminsetgithub: 47655
2018-05-29 14:18:00mkieversetmessages: + msg318035
2018-05-27 17:09:44mkieversetpull_requests: + pull_request6776
2018-04-22 17:33:22serhiy.storchakasetmessages: + msg315624
2018-04-22 17:09:37mkieversetmessages: + msg315621
2018-03-19 23:04:49mkieversetnosy: + mkiever
2013-09-15 11:03:03serhiy.storchakasetnosy: + serhiy.storchaka

versions: + Python 3.4, - Python 3.3
2013-05-04 10:45:45alex.rodassetnosy: + alex.rodas
2012-07-11 12:13:48dghjfrdjsetmessages: + msg165254
2012-07-11 08:29:57marksetnosy: + mark
messages: + msg165234
2012-04-03 18:50:48asvetlovsetnosy: + asvetlov
2011-01-31 20:44:31dghjfrdjsetnosy: + dghjfrdj
messages: + msg127658
2010-12-22 02:29:21r.david.murraysetstage: patch review
type: enhancement
versions: + Python 3.3, - Python 2.6, Python 3.0
2008-07-19 16:35:41gpolosetfiles: - event_generate__data.diff
2008-07-19 15:33:10gpolosetfiles: + event_generate__data2.diff
messages: + msg70040
2008-07-18 12:52:45gpolocreate