| msg69951 - (view) |
Author: Guilherme Polo (gpolo) *  |
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. 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('<>', data=root)) root.bind('<>', handle_it) root.mainloop() |
|
|
| msg70040 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2008-07-19 15:33 |
| 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. |
|
|
| msg127658 - (view) |
Author: O.C. (dghjfrdj) |
Date: 2011-01-31 20:44 |
| 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. |
|
|
| 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 http://www.tcl.tk/man/tcl8.5/TkCmd/event.htm#M16 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, 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 (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. |
|
|
| 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) * |
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... |
|
|