Here is another problem I can't fix.

bind $::w <Control-Left> {p.SwitchTabs "left"; break}
bind $::w <Control-Right> {p.SwitchTabs "right"; break}

The problem is, a treeview usually has the focus. So when I press
<Control-Left> or <Control-Right>, the tree selection changes as
if I had just pressed the bare Left/Right key.

I though "break" was supposed to prevent that. No?

--
Luc
>>

Luc <luc@sep.invalid> schrieb:

>Here is another problem I can't fix.
>
>bind $::w <Control-Left> {p.SwitchTabs "left"; break}
>bind $::w <Control-Right> {p.SwitchTabs "right"; break}
>
>The problem is, a treeview usually has the focus. So when I press
><Control-Left> or <Control-Right>, the tree selection changes as
>if I had just pressed the bare Left/Right key.
>
>I though "break" was supposed to prevent that. No?
What works for me is
return -code break
HTH
Helmut

On Sun, 14 May 2023 20:13:17 +0200, Helmut Giese wrote:

> Luc <luc@sep.invalid> schrieb:
>
> >Here is another problem I can't fix.
> >
> >bind $::w <Control-Left> {p.SwitchTabs "left";
> >break} bind $::w <Control-Right> {p.SwitchTabs "right";
> >break}
> >
> >The problem is, a treeview usually has the focus. So when I press
> ><Control-Left> or <Control-Right>, the tree selection changes as
> >if I had just pressed the bare Left/Right key.
> >
> >I though "break" was supposed to prevent that. No?

> What works for me is
> return -code break
> HTH
> Helmut

Thanks, but it doesn't work for me. The problem remains.

--
Luc
>>

Luc <luc@sep.invalid> wrote:
> Here is another problem I can't fix.
>
> bind $::w <Control-Left> {p.SwitchTabs "left"; break}
> bind $::w <Control-Right> {p.SwitchTabs "right"; break}
>
> The problem is, a treeview usually has the focus. So when I press
><Control-Left> or <Control-Right>, the tree selection changes as
> if I had just pressed the bare Left/Right key.
>
> I though "break" was supposed to prevent that. No?

The other reply about "return -code break" would have been relevant
only, when called from the body of a procedure that would be called
from the binding... e.g. if procedure p.SwitchTabs were yours,
then from within that you'd do the return -code break.

If break (directly in the binding) doesn't work for you, then the
problem is elsewhere...

First check would be, whether your break is even reached. make the
binding look like: {p.SwitchTabs "left"; puts checkpoint; break}
and check, if you get to see the checkpoint in the console.
if you don't see it, put a second puts checkpoint2 before p.SwitchTabs.
If you then see checkpoint2, but not checkpoint, then the procedure
p.SwitchTabs seems to do some other return -code ... trick that would
cause your break to not be executed.

If you see the checkpoint, (or don't see the checkpoint2) then you need
to check the "bindtags" for the widget $::w maybe in that sequence
some other thing fires first, and already handes Right/Left, before it
gets to your binding.

Another hint: carefully read the documentation for "bindtags".

On Sun, 14 May 2023 14:38:11 -0300
Luc <luc@sep.invalid> wrote:

> Here is another problem I can't fix.
>
> bind $::w <Control-Left> {p.SwitchTabs "left"; break}
> bind $::w <Control-Right> {p.SwitchTabs "right"; break}
>
> The problem is, a treeview usually has the focus. So when I press
> <Control-Left> or <Control-Right>, the tree selection changes as
> if I had just pressed the bare Left/Right key.
>
> I though "break" was supposed to prevent that. No?
> --
> Luc

Events are delivered to the widget which has the focus, and they are
processed in the order given by the [bindtags] command. I pseudocode,
a Tcl script implementing bindings does

foreach tag [bindtags $win] {
uplevel #0 [bind $tag $sequence]
}

By default, a wiget binding tags are, in order, its name, its class,
its nearest toplevel up in the window hierarchy and the "all" tag.

list $win [winfo class $win] [winfo toplevel $win] "all"

In your case, I assume $::w is a toplevel widget, so it comes after
the treeview class tag (Treeview), on which are set all the bindings
that define treeview's default behaviour.

So when your binding fires, the treeview already has changed the selection.
The [break] command only avoids the firing of the "all" tag, should it
have any binding set to <Control-Left> or right.

As a workaround, you can try setting a more specific binding on Treeview
(untested)

bind Treeview <Control-Left> {# do nothing}
bind Treeview <Control-Right> {# do nothing}

--
Emiliano Gavilan <emilianogavilan@gmail.com>

On Tue, 16 May 2023 14:52:11 -0300, Emiliano Gavilan wrote:

> Events are delivered to the widget which has the focus, and they are
> processed in the order given by the [bindtags] command. I pseudocode,
> a Tcl script implementing bindings does
>
> foreach tag [bindtags $win] {
> uplevel #0 [bind $tag $sequence]
> }
>
> By default, a wiget binding tags are, in order, its name, its class,
> its nearest toplevel up in the window hierarchy and the "all" tag.
>
> list $win [winfo class $win] [winfo toplevel $win] "all"
>
> In your case, I assume $::w is a toplevel widget, so it comes after
> the treeview class tag (Treeview), on which are set all the bindings
> that define treeview's default behaviour.
>
> So when your binding fires, the treeview already has changed the
> selection. The [break] command only avoids the firing of the "all" tag,
> should it have any binding set to <Control-Left> or right.
>
> As a workaround, you can try setting a more specific binding on Treeview
> (untested)
>
> bind Treeview <Control-Left> {# do nothing}
> bind Treeview <Control-Right> {# do nothing}

It works. Thank you!

However,

This doesn't work:

bind Treeview <Control-Left> {break}
bind Treeview <Control-Right> {break}
bind $::w <Control-Left> {p.SwitchTabs "left"; break}
bind $::w <Control-Right> {p.SwitchTabs "right"; break}

But this works:

bind Treeview <Control-Left> {break}
bind Treeview <Control-Right> {break}
bind Treeview <Control-Left> {p.SwitchTabs "left"; break}
bind Treeview <Control-Right> {p.SwitchTabs "right"; break}

So not only do I have to kill an existing binding, I have to redefine it
even for a specific widget (Treeview) or else it won't work.

Seeing that I intend to let the user select their own keyboard
combinations for every action, I suspect this is going to be a bit of
a lot of headache for me.

--
Luc
>>

Luc <luc@sep.invalid> wrote:
> On Tue, 16 May 2023 14:52:11 -0300, Emiliano Gavilan wrote:
>
>> Events are delivered to the widget which has the focus, and they are
>> processed in the order given by the [bindtags] command. I pseudocode,
>> a Tcl script implementing bindings does
>>
>> foreach tag [bindtags $win] {
>> uplevel #0 [bind $tag $sequence]
>> }
>>
>> By default, a wiget binding tags are, in order, its name, its class,
>> its nearest toplevel up in the window hierarchy and the "all" tag.
>>
>> list $win [winfo class $win] [winfo toplevel $win] "all"
>>
>> In your case, I assume $::w is a toplevel widget, so it comes after
>> the treeview class tag (Treeview), on which are set all the bindings
>> that define treeview's default behaviour.
>>
>> So when your binding fires, the treeview already has changed the
>> selection. The [break] command only avoids the firing of the "all" tag,
>> should it have any binding set to <Control-Left> or right.
>>
>> As a workaround, you can try setting a more specific binding on Treeview
>> (untested)
>>
>> bind Treeview <Control-Left> {# do nothing}
>> bind Treeview <Control-Right> {# do nothing}
>
>
> It works. Thank you!
>
> However,
>
> This doesn't work:
>
> bind Treeview <Control-Left> {break}
> bind Treeview <Control-Right> {break}

Changing the binding to 'break' is *very* different from changing it to
a 'comment' (which does nothing). Alternately, an empty string
completely removes the existing binding.

> bind $::w <Control-Left> {p.SwitchTabs "left"; break}
> bind $::w <Control-Right> {p.SwitchTabs "right"; break}

Because the bindtags execute first, and because you changed to 'break',
you prevented your binding on $::w from firing, because the 'break' in
the bindtags stopped further execution of additional bindings for the event.

> But this works:
>
> bind Treeview <Control-Left> {break}
> bind Treeview <Control-Right> {break}
> bind Treeview <Control-Left> {p.SwitchTabs "left"; break}
> bind Treeview <Control-Right> {p.SwitchTabs "right"; break}

Your second two replace your first two, so the above is exactly
identical to this:

> bind Treeview <Control-Left> {p.SwitchTabs "left"; break}
> bind Treeview <Control-Right> {p.SwitchTabs "right"; break}

Which means you have replaced the existing default binding with your
own. And without a 'break' messing things up, your bindings get
executed.

> So not only do I have to kill an existing binding, I have to redefine it
> even for a specific widget (Treeview) or else it won't work.

Redefining it is exactly "killing an existing binding". There's no
'two step' process here. You don't have to 'first kill' then
'redefine'. Just bind a new script (with no + prefix), and that
replaces the old script.

Another poster in a different thread suggested you "carefully read the
bind manpage" -- you really *do* need to do so.

> Seeing that I intend to let the user select their own keyboard
> combinations for every action, I suspect this is going to be a bit of
> a lot of headache for me.

Building anything that is super flexible (such as user selection of
their own keyboard bindings) is always going to be a "bit of a headache
for you".