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