Tkinter: tkButtonDown, tkButtonEnter, tkButtonInvoke, tkButtonLeave,tkButtonUp

[akineko]

Hi everyone,

This is a memorandum so that other people can share the info.

The following methods are declared in the Tkinter Button class.
tkButtonDown(), tkButtonEnter(), tkButtonInvoke(), tkButtonLeave(),
tkButtonUp()
However, they are not working, when you try, you will get:

_tkinter.TclError: invalid command name "tkButtonLeave"

The bindings in the Tkinter are mapping them to non-existing tk
methods.
I needed to use the method badly and I couldn't find any clear
solution for this. So, I spent time to solve this.

tkButtonLeave(), for example, is declared as follows:

Tkinter.py line 2005 of 3759
def tkButtonLeave(self, *dummy):
self.tk.call('tkButtonLeave', self._w)

Now, in the Tk source distribution, I found the following:
unsupported.tcl
# Commands provided by Tk without official support. Use them at your
# own risk. They may change or go away without notice.

namespace eval ::tk::unsupported {

# Map from the old global names of Tk private commands to their
# new namespace-encapsulated names.

variable PrivateCommands
array set PrivateCommands {
tkButtonAutoInvoke ::tk::ButtonAutoInvoke
tkButtonDown ::tk::ButtonDown
tkButtonEnter ::tk::ButtonEnter
tkButtonInvoke ::tk::ButtonInvoke
tkButtonLeave ::tk::ButtonLeave
tkButtonUp ::tk::ButtonUp
.... snip ...

This seems suggesting that the Tkinter bindings are binding obsolete
tk methods.
And, the method should be called seems ::tk::ButtonLeave, instead.

I placed the following into my Tkinter code and it worked.
self.btn.tk.call('::tk::ButtonLeave', self.btn._w)

//
Summary:
(1) tkButtonDown, tkButtonEnter, tkButtonInvoke, tkButtonLeave,
tkButtonUp are not working.
(2) Bindings are not correct
(2) Workaround is call correct tk methods directly

I hope future Tkinter will be corrected so that the methods are
available as documented.

Best regards,
Aki-

[Guilherme Polo]

On Mon, Sep 1, 2008 at 7:45 PM, akineko <ak*****@gmail.comwrote:

Hi everyone,

This is a memorandum so that other people can share the info.

The following methods are declared in the Tkinter Button class.
tkButtonDown(), tkButtonEnter(), tkButtonInvoke(), tkButtonLeave(),
tkButtonUp()
However, they are not working, when you try, you will get:

_tkinter.TclError: invalid command name "tkButtonLeave"

The bindings in the Tkinter are mapping them to non-existing tk
methods.
I needed to use the method badly and I couldn't find any clear
solution for this.

Are you trying to simulate clicks ? You should be doing it using
event_generate, more below.

So, I spent time to solve this.

tkButtonLeave(), for example, is declared as follows:

Tkinter.py line 2005 of 3759
def tkButtonLeave(self, *dummy):
self.tk.call('tkButtonLeave', self._w)

Now, in the Tk source distribution, I found the following:
unsupported.tcl
# Commands provided by Tk without official support. Use them at your
# own risk. They may change or go away without notice.

namespace eval ::tk::unsupported {

# Map from the old global names of Tk private commands to their
# new namespace-encapsulated names.

variable PrivateCommands
array set PrivateCommands {
tkButtonAutoInvoke ::tk::ButtonAutoInvoke
tkButtonDown ::tk::ButtonDown
tkButtonEnter ::tk::ButtonEnter
tkButtonInvoke ::tk::ButtonInvoke
tkButtonLeave ::tk::ButtonLeave
tkButtonUp ::tk::ButtonUp
... snip ...

You are looking at the wrong place, try looking at library/button.tcl
Now, why I said about using event_generate instead of calling those
methods yourself.. tk sets several bindings that varies between
platforms for all these things you are trying to do, and they end up
calling these commands you are trying to call yourself. So, for
instance, given that you have a button:

btn = Tkinter.Button()

to get tk::ButtonEnter called, you should be doing:

btn.event_generate("<Enter>")

and this will work for other those other events too, Leave (Leave),
Button-1 (Down), ButtonRelease-1 (Up), space (Invoke). The remaining
one to talk about is this "ButtonAutoInvoke", which I'm unsure if you
really need it, but, if you do, you could use btn.invoke() supposing
the button has an associated callback which will use "after" to
schedule another btn.invoke().

>
This seems suggesting that the Tkinter bindings are binding obsolete
tk methods.
And, the method should be called seems ::tk::ButtonLeave, instead.

I placed the following into my Tkinter code and it worked.
self.btn.tk.call('::tk::ButtonLeave', self.btn._w)

//
Summary:
(1) tkButtonDown, tkButtonEnter, tkButtonInvoke, tkButtonLeave,
tkButtonUp are not working.
(2) Bindings are not correct
(2) Workaround is call correct tk methods directly

I hope future Tkinter will be corrected so that the methods are
available as documented.

You should expect them to be totally removed from Tkinter actually.

>
Best regards,
Aki-
--
http://mail.python.org/mailman/listinfo/python-list

--
-- Guilherme H. Polo Goncalves

[akineko]

On Sep 1, 5:52 pm, "Guilherme Polo" <[e-mail]:

Are you trying to simulate clicks ? You should be doing it using
event_generate, more below.

Actually, I was trying to implement a "sticky" button.
(Button Release is done later by another event)

I already tried event_generate.
It worked as far as I didn't touch other widgets.
But somehow it failed to work if event_generate is called after other
widgets are activated.

You should expect them to be totally removed from Tkinter actually.

Sad to hear that. Controlling the button behaviour explicitly may not
be a common thing to do but it is still necessary thing to do. But you
gave me enough insights.

Aki-

[Guilherme Polo]

On Mon, Sep 1, 2008 at 10:09 PM, akineko <ak*****@gmail.comwrote:

On Sep 1, 5:52 pm, "Guilherme Polo" <[e-mail]:

>Are you trying to simulate clicks ? You should be doing it using
event_generate, more below.

Actually, I was trying to implement a "sticky" button.
(Button Release is done later by another event)

I already tried event_generate.
It worked as far as I didn't touch other widgets.
But somehow it failed to work if event_generate is called after other
widgets are activated.

>You should expect them to be totally removed from Tkinter actually.

Sad to hear that. Controlling the button behaviour explicitly may not
be a common thing to do but it is still necessary thing to do. But you
gave me enough insights.

This is an illusion you have, calling those methods are not the way
for explicitly controlling button's behavior, not more than generating
proper events. The explicit way is to not use a button, instead
(ab)use Canvas.

>
Aki-
--
http://mail.python.org/mailman/listinfo/python-list

--
-- Guilherme H. Polo Goncalves

[akineko]

On Sep 1, 6:34 pm, "Guilherme Polo" <[e-mail]:

This is an illusion you have, calling those methods are not the way
for explicitly controlling button's behavior, not more than generating
proper events. The explicit way is to not use a button, instead
(ab)use Canvas.

Some of my custom widgets used Canvas.
When I designed the "sticky" button widget, I briefly considered use
of Canvas but I rejected because the one I wanted is nothing but
Button (except "sticky" behaviour).
I understand that use of Canvas provides greater flexibility but I
felt it was over-kill.
Your insights are very helpful for me and other people when designing
a custom widget.

Aki-

[Guilherme Polo]

On Mon, Sep 1, 2008 at 11:01 PM, akineko <ak*****@gmail.comwrote:

On Sep 1, 6:34 pm, "Guilherme Polo" <[e-mail]:

>This is an illusion you have, calling those methods are not the way
for explicitly controlling button's behavior, not more than generating
proper events. The explicit way is to not use a button, instead
(ab)use Canvas.

Some of my custom widgets used Canvas.
When I designed the "sticky" button widget, I briefly considered use
of Canvas but I rejected because the one I wanted is nothing but
Button (except "sticky" behaviour).

Can you clarify what is this "sticky" behavior ? Are you referring to
a toggle button ? If yes, then you might be after a simple
Checkbutton:

checkbutton = Tkinter.Checkbutton(indicatoron=False, text='test')

I understand that use of Canvas provides greater flexibility but I
felt it was over-kill.
Your insights are very helpful for me and other people when designing
a custom widget.

Aki-
--
http://mail.python.org/mailman/listinfo/python-list

--
-- Guilherme H. Polo Goncalves

[akineko]

On Sep 1, 8:28 pm, "Guilherme Polo" <[e-mail]:

Can you clarify what is this "sticky" behavior ? Are you referring to
a toggle button ? If yes, then you might be after a simple
Checkbutton:

checkbutton = Tkinter.Checkbutton(indicatoron=False, text='test')

I wouldn't spend days to create a custom widget to mimick the
Checkbutton ;-)

I don't need to describe the detail but once the button was pressed
for a bit while, a command is sent through communication.
The button is left being ButtonDown ("sticky") until an
acknowledgement is sent back through communication.
This is a way to let the user know the action was acknowledged at
another end.

I think probably very few people needs such widget.

Aki-

[Guilherme Polo]

On Tue, Sep 2, 2008 at 12:44 AM, akineko <ak*****@gmail.comwrote:

On Sep 1, 8:28 pm, "Guilherme Polo" <[e-mail]:

>Can you clarify what is this "sticky" behavior ? Are you referring to
a toggle button ? If yes, then you might be after a simple
Checkbutton:

checkbutton = Tkinter.Checkbutton(indicatoron=False, text='test')

I wouldn't spend days to create a custom widget to mimick the
Checkbutton ;-)

I don't need to describe the detail but once the button was pressed
for a bit while, a command is sent through communication.
The button is left being ButtonDown ("sticky") until an
acknowledgement is sent back through communication.
This is a way to let the user know the action was acknowledged at
another end.

I think probably very few people needs such widget.

Did you even try creating a checkbutton with indicatoron=False ? You
could get surprised.

>
Aki-

--
http://mail.python.org/mailman/listinfo/python-list

--
-- Guilherme H. Polo Goncalves

[akineko]

On Sep 2, 5:46 am, "Guilherme Polo" <[e-mail]:

Did you even try creating a checkbutton with indicatoron=False ? You
could get surprised.

I didn't. My perception of checkbutton was a button with a check.
So, I tried as you suggested.
Yes, you are right. It is almost what I wanted (sticky behaviour).
By ignoring the ButtonRelease and Leave events, yes, it can perfectly
meet my requirements.
As checkbutton has deselect() method, this is a better approach, I
have to admit.

Thank you for showing me the correct way to implement.

Aki-