I define a binding that should call a procedure when the Tab key is pressed. Let's say:

bind all <Key-Tab> "puts works!"

In Tcl 8.6.12 nothing happens when I press the Tab key. in Tcl 8.6.9 the "works!" string is written to the console as expected.

Have I missed some major change or is this a bug?
Is there a way to make this work?

Thanks
Alexandru

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andreas Leitgeb <avl@logic.at> wrote:

Maybe you put the "all" entry too far back for those widgets, so other bindings get it first, and these other bindings might handle the event
and break further propagation to your handler.

Starting a new wish:

% bind all <Key-Tab> "puts works!"
# click on the empty main window and Tab -> "works!"

% pack [entry .e1]
% pack [entry .e2]

# click on any of the entry widgets and Tab -> "works!"

% bindtags .e1
.e1 Entry . all

% bind .e1 <Key-Tab> { puts ".e1 is it" }

# now, Tab in .e1 writes both ".e1 is it" and "works!" in that order.

% bind .e1 <Key-Tab> { puts ".e1 is it"; break }

# now, Tab in .e1 writes only ".e1 is it"

I suspect something like that happening in your code.


PS: Only 8.6.8 here.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alexandru <alexandru.dadalau@meshparts.de> wrote:

I define a binding that should call a procedure when the Tab key is pressed. Let's say:
bind all <Key-Tab> "puts works!"
In Tcl 8.6.12 nothing happens when I press the Tab key. in Tcl 8.6.9 the "works!" string is written to the console as expected.
Have I missed some major change or is this a bug?
Is there a way to make this work?

Just recently you posted snippets of code where you were customizing
the bindtags-list for certain widgets.

Maybe you put the "all" entry too far back for those widgets, so other
bindings get it first, and these other bindings might handle the event
and break further propagation to your handler.

If you're running the same overall code with 8.6.12 versus 8.6.9,
then maybe the code has separate branches for specific versions,
to account for features not yet in 8.6.9...

And finally, it is of course possible that there's indeed some regression
in 8.6.12 ... - In that case, a simple testcase would be nice.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andreas Leitgeb schrieb am Dienstag, 1. Februar 2022 um 15:45:58 UTC+1:

Andreas Leitgeb <a...@logic.at> wrote:

Maybe you put the "all" entry too far back for those widgets, so other bindings get it first, and these other bindings might handle the event
and break further propagation to your handler.

Starting a new wish:

% bind all <Key-Tab> "puts works!"
# click on the empty main window and Tab -> "works!"

% pack [entry .e1]
% pack [entry .e2]

# click on any of the entry widgets and Tab -> "works!"

% bindtags .e1
.e1 Entry . all

% bind .e1 <Key-Tab> { puts ".e1 is it" }

# now, Tab in .e1 writes both ".e1 is it" and "works!" in that order.

% bind .e1 <Key-Tab> { puts ".e1 is it"; break }

# now, Tab in .e1 writes only ".e1 is it"

I suspect something like that happening in your code.

PS: Only 8.6.8 here.

Thanks, but I already did all the testing needed before writing the post here. I also suspected it could be someting elese in my code so I did exactly what you did: Opened a new wish and tested the binding on the empty toplevel window. In 8.6.12 nothing happens, the binding to tab does not fire anymore. Besides, other bindings to e.
g. Return or Escape are working on both Tcl versions.
So it must be a bug.

Could anyone test with 8.6.12?

Simply open the wish console and input:
bind all <Key-Tab> "puts works!"

Then put the focus on the empty toplevel and press Tab key.
Check if the woks! output is generated.

Thanks
Alexandru

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 01.02.2022 um 21:46 schrieb Alexandru:

Andreas Leitgeb schrieb am Dienstag, 1. Februar 2022 um 15:45:58 UTC+1:

Andreas Leitgeb <a...@logic.at> wrote:

Maybe you put the "all" entry too far back for those widgets, so other
bindings get it first, and these other bindings might handle the event
and break further propagation to your handler.

Starting a new wish:

% bind all <Key-Tab> "puts works!"
# click on the empty main window and Tab -> "works!"

% pack [entry .e1]
% pack [entry .e2]

# click on any of the entry widgets and Tab -> "works!"

% bindtags .e1
.e1 Entry . all

% bind .e1 <Key-Tab> { puts ".e1 is it" }

# now, Tab in .e1 writes both ".e1 is it" and "works!" in that order.

% bind .e1 <Key-Tab> { puts ".e1 is it"; break }

# now, Tab in .e1 writes only ".e1 is it"

I suspect something like that happening in your code.


PS: Only 8.6.8 here.

Thanks, but I already did all the testing needed before writing the post here.
I also suspected it could be someting elese in my code so I did exactly what you did: Opened a new wish and tested the binding on the empty toplevel window. In 8.6.12 nothing happens, the binding to tab does not fire anymore. Besides, other bindings to

e.g. Return or Escape are working on both Tcl versions.

So it must be a bug.

Could anyone test with 8.6.12?

Simply open the wish console and input:
bind all <Key-Tab> "puts works!"

Then put the focus on the empty toplevel and press Tab key.
Check if the woks! output is generated.

Thanks
Alexandru

It does not work since 8.6.10.
Tested 8.6.9, 8.6.10, 8.6.11, 8.6.12, 8.7.a5.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul Obermeier schrieb am Dienstag, 1. Februar 2022 um 23:02:29 UTC+1:

Am 01.02.2022 um 21:46 schrieb Alexandru:

Andreas Leitgeb schrieb am Dienstag, 1. Februar 2022 um 15:45:58 UTC+1:

Andreas Leitgeb <a...@logic.at> wrote:

Maybe you put the "all" entry too far back for those widgets, so other >>> bindings get it first, and these other bindings might handle the event >>> and break further propagation to your handler.

Starting a new wish:

% bind all <Key-Tab> "puts works!"
# click on the empty main window and Tab -> "works!"

% pack [entry .e1]
% pack [entry .e2]

# click on any of the entry widgets and Tab -> "works!"

% bindtags .e1
.e1 Entry . all

% bind .e1 <Key-Tab> { puts ".e1 is it" }

# now, Tab in .e1 writes both ".e1 is it" and "works!" in that order.

% bind .e1 <Key-Tab> { puts ".e1 is it"; break }

# now, Tab in .e1 writes only ".e1 is it"

I suspect something like that happening in your code.


PS: Only 8.6.8 here.

Thanks, but I already did all the testing needed before writing the post here.
I also suspected it could be someting elese in my code so I did exactly what you did: Opened a new wish and tested the binding on the empty toplevel window. In 8.6.12 nothing happens, the binding to tab does not fire anymore. Besides, other bindings

to e.g. Return or Escape are working on both Tcl versions.

So it must be a bug.

Could anyone test with 8.6.12?

Simply open the wish console and input:
bind all <Key-Tab> "puts works!"

Then put the focus on the empty toplevel and press Tab key.
Check if the woks! output is generated.

Thanks
Alexandru

It does not work since 8.6.10.
Tested 8.6.9, 8.6.10, 8.6.11, 8.6.12, 8.7.a5.

Paul

Thanks Paul for the tests.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01/02/2022 23:02, Paul Obermeier wrote:

Am 01.02.2022 um 21:46 schrieb Alexandru:

Could anyone test with 8.6.12?

Simply open the wish console and input:
bind all <Key-Tab> "puts works!"

Then put the focus on the empty toplevel and press Tab key.
Check if the woks! output is generated.

Thanks
Alexandru

It does not work since 8.6.10.
Tested 8.6.9, 8.6.10, 8.6.11, 8.6.12, 8.7.a5.

Paul

It's not that binding to <Key-Tab> doesn't work anymore. But apparently something has changed when you have both a binding for a physical event
and a virtual event that translates to the same physical event.

The "all" tag already has a binding for <<NextWindow>>, which is
associated with <Key-Tab>. If you remove that binding, the <Key-Tab>
binding starts firing when you press the Tab key.

So, while this is a change that would have been worth mentioning in the
release notes, I suppose having two bindings for essentially the same
event is probably not a good idea. The behavior in such cases is
unspecified.


Schelte.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 02.02.22 um 13:27 schrieb Schelte:

On 01/02/2022 23:02, Paul Obermeier wrote:

Am 01.02.2022 um 21:46 schrieb Alexandru:

Could anyone test with 8.6.12?

Simply open the wish console and input:
bind all <Key-Tab> "puts works!"

Then put the focus on the empty toplevel and press Tab key.
Check if the woks! output is generated.

Thanks
Alexandru

It does not work since 8.6.10.
Tested 8.6.9, 8.6.10, 8.6.11, 8.6.12, 8.7.a5.

Paul

It's not that binding to <Key-Tab> doesn't work anymore. But apparently something has changed when you have both a binding for a physical event
and a virtual event that translates to the same physical event.

The "all" tag already has a binding for <<NextWindow>>, which is
associated with <Key-Tab>. If you remove that binding, the <Key-Tab>
binding starts firing when you press the Tab key.

So, while this is a change that would have been worth mentioning in the release notes, I suppose having two bindings for essentially the same
event is probably not a good idea. The behavior in such cases is
unspecified.

Schelte.

While I fully agree with the above explanation, I just wanted to add
that *replacing* instead of *extending* the default binding for the
"all" tag is more often than not a bad idea. The Tk library script
tk.tcl contains the code snippet

event add <<PrevWindow>> <Shift-Tab>
event add <<NextWindow>> <Tab>
bind all <<NextWindow>> {tk::TabToWindow [tk_focusNext %W]}
bind all <<PrevWindow>> {tk::TabToWindow [tk_focusPrev %W]}

which implements the keyboard navigation via <Tab> and <Shif-Tab>. For
this reason, I thoroughly recommend to replace the code

bind all <Key-Tab> "puts works!"

with

bind all <<NextWindow>> {+ puts works! }

which *adds* an application-specific action to the default handling of
the <Key-Tab> event.

--
Csaba Nemethi https://www.nemethi.de mailto:csaba.nemethi@t-online.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Schelte schrieb am Mittwoch, 2. Februar 2022 um 13:27:58 UTC+1:

On 01/02/2022 23:02, Paul Obermeier wrote:

Am 01.02.2022 um 21:46 schrieb Alexandru:

Could anyone test with 8.6.12?

Simply open the wish console and input:
bind all <Key-Tab> "puts works!"

Then put the focus on the empty toplevel and press Tab key.
Check if the woks! output is generated.

Thanks
Alexandru

It does not work since 8.6.10.
Tested 8.6.9, 8.6.10, 8.6.11, 8.6.12, 8.7.a5.

Paul

It's not that binding to <Key-Tab> doesn't work anymore. But apparently something has changed when you have both a binding for a physical event
and a virtual event that translates to the same physical event.

The "all" tag already has a binding for <<NextWindow>>, which is
associated with <Key-Tab>. If you remove that binding, the <Key-Tab>
binding starts firing when you press the Tab key.

So, while this is a change that would have been worth mentioning in the release notes, I suppose having two bindings for essentially the same
event is probably not a good idea. The behavior in such cases is
unspecified.

Schelte.

Many thanks. I have replaced the <Key-Tab> with <<NextWindow>> and now it works.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

nemethi schrieb am Donnerstag, 3. Februar 2022 um 11:52:51 UTC+1:

Am 02.02.22 um 13:27 schrieb Schelte:

On 01/02/2022 23:02, Paul Obermeier wrote:

Am 01.02.2022 um 21:46 schrieb Alexandru:

Could anyone test with 8.6.12?

Simply open the wish console and input:
bind all <Key-Tab> "puts works!"

Then put the focus on the empty toplevel and press Tab key.
Check if the woks! output is generated.

Thanks
Alexandru

It does not work since 8.6.10.
Tested 8.6.9, 8.6.10, 8.6.11, 8.6.12, 8.7.a5.

Paul

It's not that binding to <Key-Tab> doesn't work anymore. But apparently something has changed when you have both a binding for a physical event and a virtual event that translates to the same physical event.

The "all" tag already has a binding for <<NextWindow>>, which is associated with <Key-Tab>. If you remove that binding, the <Key-Tab> binding starts firing when you press the Tab key.

So, while this is a change that would have been worth mentioning in the release notes, I suppose having two bindings for essentially the same event is probably not a good idea. The behavior in such cases is unspecified.

Schelte.

While I fully agree with the above explanation, I just wanted to add
that *replacing* instead of *extending* the default binding for the
"all" tag is more often than not a bad idea. The Tk library script
tk.tcl contains the code snippet

event add <<PrevWindow>> <Shift-Tab>
event add <<NextWindow>> <Tab>
bind all <<NextWindow>> {tk::TabToWindow [tk_focusNext %W]}
bind all <<PrevWindow>> {tk::TabToWindow [tk_focusPrev %W]}

which implements the keyboard navigation via <Tab> and <Shif-Tab>. For
this reason, I thoroughly recommend to replace the code
bind all <Key-Tab> "puts works!"
with

bind all <<NextWindow>> {+ puts works! }

which *adds* an application-specific action to the default handling of
the <Key-Tab> event.

--
Csaba Nemethi https://www.nemethi.de mailto:csaba....@t-online.de

It's is actually my intention to deactivate all default bindings. Why is this wrong?
To explain more: The user activates a specific function (context) in which the Tab key triggers only specific actions. I want that the key always triggers that specific action and nothing else. After the user exits that function or context, the old key
bindings are restored.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 03.02.22 um 13:41 schrieb Alexandru:

nemethi schrieb am Donnerstag, 3. Februar 2022 um 11:52:51 UTC+1:

Am 02.02.22 um 13:27 schrieb Schelte:

On 01/02/2022 23:02, Paul Obermeier wrote:

Am 01.02.2022 um 21:46 schrieb Alexandru:

Could anyone test with 8.6.12?

Simply open the wish console and input:
bind all <Key-Tab> "puts works!"

Then put the focus on the empty toplevel and press Tab key.
Check if the woks! output is generated.

Thanks
Alexandru

It does not work since 8.6.10.
Tested 8.6.9, 8.6.10, 8.6.11, 8.6.12, 8.7.a5.

Paul

It's not that binding to <Key-Tab> doesn't work anymore. But apparently
something has changed when you have both a binding for a physical event
and a virtual event that translates to the same physical event.

The "all" tag already has a binding for <<NextWindow>>, which is
associated with <Key-Tab>. If you remove that binding, the <Key-Tab>
binding starts firing when you press the Tab key.

So, while this is a change that would have been worth mentioning in the
release notes, I suppose having two bindings for essentially the same
event is probably not a good idea. The behavior in such cases is
unspecified.


Schelte.

While I fully agree with the above explanation, I just wanted to add
that *replacing* instead of *extending* the default binding for the
"all" tag is more often than not a bad idea. The Tk library script
tk.tcl contains the code snippet

event add <<PrevWindow>> <Shift-Tab>
event add <<NextWindow>> <Tab>
bind all <<NextWindow>> {tk::TabToWindow [tk_focusNext %W]}
bind all <<PrevWindow>> {tk::TabToWindow [tk_focusPrev %W]}

which implements the keyboard navigation via <Tab> and <Shif-Tab>. For
this reason, I thoroughly recommend to replace the code
bind all <Key-Tab> "puts works!"
with

bind all <<NextWindow>> {+ puts works! }

which *adds* an application-specific action to the default handling of
the <Key-Tab> event.

--
Csaba Nemethi https://www.nemethi.de mailto:csaba....@t-online.de

It's is actually my intention to deactivate all default bindings. Why is this wrong?
To explain more: The user activates a specific function (context) in which the Tab key triggers only specific actions. I want that the key always triggers that specific action and nothing else. After the user exits that function or context, the old key

bindings are restored.

I wrote: "... is more often than not a bad idea". Of course, if
replacing the default binding with an application-specific one is
intentional then this is not necessarily a bad idea. If can even be a
good one, depending on the use case in question.

--
Csaba Nemethi https://www.nemethi.de mailto:csaba.nemethi@t-online.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)