homepage

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.:
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
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.

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
* 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,
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.
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, http://www.tcl.tk/man/tcl8.5/TkCmd/bind.htm#M24 :
* 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 (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.

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.

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...