Event generation has limits

Mo DeJong posted that "The main problem I have seen with event generate is the lack of an easy way to generate events as if the user was typing into the keyboard. What I mean by this is that you need to know the exact Tk widget that the event will be delivered to. If you have some application that pops up a dialog, you can't just say "type into the dialog". You need to figure out the widget path name of the widget that should have the focus (and you may need to set the focus). It can be quite a pain. For example, some megawidget don't provide any way to query for the contained window path names (like tk_getOpenFile for example). It would be much better if you could just direct the event to the toplevel window and have it redirect the event to the widget with the focus. There are other cases where the internal window names might change based on some global variable that keeps track of how many instances of that window are active, there may be no way to find the real window name short of a recursive winfo children mess.

There also does not seem to be any way to generate key press events on Windows Tk does not know about. The WM screen for example. I wanted to write a test to see if the WM_* protocol commands were getting invoked. It did not seem to be possible. Same goes for any native windows, like the printer dialog in Windows. I also did not see how you could send events to other windows, one could test to see if the grab was working in this way."


The next day, Jeff added "It's not great as a general record and playback because too many event generate calls for moving the mouse around would be a bit slow. However, it can pretty much simulate all the events that Tk widgets otherwise see. It doesn't work on non-Tk widgets. Some events you have to be careful to use correctly (like for keyboard events the widget must have focus first)."


There's also no way to "replicate" events. Sometimes in a megawidget I'd like to take an event, change something about the event, then pass it on to another widget. Only, I can't get at all of the various bits of the event (x, y, etc) unless I explicitly capture all of those up front.

I also wish there were a way to attach arbitrary data to an event. There have been times when I've wanted to use events as a communication mechanism between widgets. The best one can do is store data in a global variable prior to generating an event, and have the event handler read from that array. Not a very good way to do things...

An example of this might be something like "event generate . <<ShowStatus>> -data "loading file..."" (a contrived example, but somewhat illustrates the point).