simulating button clicks on a Tcl/Tk application
canvas_remix
I have a Tcl/Tk based application and would like to simulate all the
button clicks, key-typing events etc.
For starting, we can do just the mouse clicks.
But it looks like the event generate command does not work in the
following code :
button .b -command "puts command_executed"
pack .b
event generate .b
Please help.
suchenwi
pathName invoke
Invoke the Tcl command associated with the button, if there is one.
The return value is the return value from the Tcl command, or an empty
string if there is no command associated with the button. This command
is ignored if the button's state is disabled.
So in your case, .b invoke
canvas_remix
I have a goood number of buttons, textboxes, entry widgets, menus and
etc. GUI elements in my Tcl/Tk application so that
finding the pathname and then calling invoke (not application to non-
buttons ?) is not an options.
I am looking for something like
foreach event $list_of_events {
bind all $event "+puts event generate %W $event ... "
}
Basically a user actions' replayer kind of thing.
Bryan Oakley
There's a bit more to using event generate than juts giving a widget
path. Have you read the man page? For starters, you have to say which
event you want to generate.
Also, for some types of events (it's been years so I've long since
forgotten) you have to first generate an <Enter> event. It could very
well be buttons you need to do that for. And of course, for widgets like
entries you have to set the focus before the events will be recognized.
Writing a sort of playback script is doable (mostly *) but likely takes
more work than you're expecting. Is your goal to simulate a bunch of
events, or do you just want to automte the testing of a GUI?
* I say "mostly" because, if you are on windows it is impossible to use
[event generate] to drive menus. On that platform events over menus are
handled internally by Windows instead of by tk.
Gerald W. Lester
> canvas_remix wrote:
>...
>
> Writing a sort of playback script is doable (mostly *) but likely takes
> more work than you're expecting. Is your goal to simulate a bunch of
> events, or do you just want to automte the testing of a GUI?
>
> * I say "mostly" because, if you are on windows it is impossible to use
> [event generate] to drive menus. On that platform events over menus are
> handled internally by Windows instead of by tk.
Actually on Windows you can do it, you just need TWAPI. There was a paper
given on it at last year's Tcl/Tk Conference.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
canvas_remix
> canvas_remix wrote:
> > Hi,
>
> > I have a Tcl/Tk based application and would like to simulate all the
> > button clicks, key-typing events etc.
> > For starting, we can do just the mouse clicks.
> > But it looks like the event generate command does not work in the
> > following code :
>
> > button .b -command "puts command_executed"
> > pack .b
> > event generate .b
>
> There's a bit more to using event generate than juts giving a widget
> path. Have you read the man page? For starters, you have to say which
> event you want to generate.
>
> Also, for some types of events (it's been years so I've long since
> forgotten) you have to first generate an <Enter> event. It could very
> well be buttons you need to do that for. And of course, for widgets like
> entries you have to set the focus before the events will be recognized.
>
> Writing a sort of playback script is doable (mostly *) but likely takes
> more work than you're expecting. Is your goal to simulate a bunch of
> events, or do you just want to automte the testing of a GUI?
>
We need to automate the testing of a GUI.
> * I say "mostly" because, if you are on windows it is impossible to use
> [event generate] to drive menus. On that platform events over menus are
> handled internally by Windows instead of by tk.
Is there any small code available similar to the one I have given
above which can do the same thing ?
Glenn Jackman
> We need to automate the testing of a GUI.
You might want to investigate Android: http://wiki.tcl.tk/android
--
Glenn Jackman
"You can only be young once. But you can always be immature." -- Dave Barry
---
>
> Is there any small code available similar to the one I have given
> above which can do the same thing ?
>
For user playback of button clicks I've used this in the past:
proc click_button {button} {
event generate $button <Enter>
event generate $button <ButtonPress> -button 1
after 100 "event generate $button <ButtonRelease> -button 1"
}
I don't know the details of how the events work, but it seems
that the release is what actually triggers the button's command
to be called and having the delay lets you actually "see" the
button being clicked.
(bin) 2 % button .b1 -text "b1" -command "puts b1"
.b1
(bin) 3 % button .b2 -text "b2" -command "puts b2"
.b2
(bin) 4 % pack .b1
(bin) 5 % pack .b2
(bin) 6 % click_button .b1
after#9
b1
(bin) 7 % click_button .b2
after#10
b2
Hope that helps,
Dan
Cameron Laird
.
.
Buttons have a complex of behaviors people expect of them, but a
binding to <ButtonRelease> is indeed the single one that most closely
matches the "Push me" expectations of most users.
The original questioner will want to read <URL: http://wiki.tcl.tk/8813 >.
Bryan Oakley
>
> proc click_button {button} {
> event generate $button <Enter>
> event generate $button <ButtonPress> -button 1
> after 100 "event generate $button <ButtonRelease> -button 1"
> }
Not that it likely matters in most real-world situations, but the above
code will break if your widget names have spaces in them (which is
possible, but rarely done for practical reasons). You can avoid that by
using list:
after 100 [list event generate $button <ButtonRelease> -button 1]
--
Bryan "Feeling slightly pedantic this morning" Oakley
http://www.tclscripting.com