Listbox is returning former selection
ZB
#v+
% set aList {one two three four}
one two three four
% pack [listbox .l -listvariable$aList]
% bind Listbox <<ListboxSelect>> { puts [%W get active] }
#v-
It's easy to find out using the example above, that "get active" is always
returning _former_ selection, not the current one (not the one presently
"clicked"). How could that "delay" be eliminated?
Yes, I understand: at the moment of "click" that former one had focus
(marked with dotted line) - which will now be moved "on release" - so exactly
that one has been considered as "active". The problem is, that it doesn't
make any sense; the "active" should be the one I'm currently choosing. Not
the one clicked - say - about quarter ago.
--
ZB
Jeff Hobbs
It's good that you recognize the binding order is the issue, so what
to do about it?
Don't rely on 'active', instead use the other features that listbox
provides.
In you case, this is in the Tk usage FAQ at
http://tcl.sourceforge.net/faqs/tk/#listbox/curselection.
Jeff
ZB
> It's good that you recognize the binding order is the issue, so what
> to do about it?
> Don't rely on 'active', instead use the other features that listbox
> provides.
>
> In you case, this is in the Tk usage FAQ at
> http://tcl.sourceforge.net/faqs/tk/#listbox/curselection.
>
> Jeff
Willing to keep <<ListboxSelect>> binding, I made it somewhat different way:
bind Listbox <<ListboxSelect>> { puts [%W get [lindex [%W curselection]]] }
...but this seemed a bit overcomplicated to me, when there is "get active"
index provided. Unfortunately, its reaction doesn't strictly follow its
name.
--
ZB
Csaba Nemethi
Think a bit more about it, and you will see that it is not right to
state that "it doesn't make any sense". Changes in the selection are
handled on <Button-1> events, while the active index is set on
<ButtonRelease-1>. This has always been this way, and not only in Tk,
but in other GUI frameworks, too.
--
Csaba Nemethi http://www.nemethi.de mailto:csaba....@t-online.de
ZB
> Think a bit more about it, and you will see that it is not right to
> state that "it doesn't make any sense". Changes in the selection are
> handled on <Button-1> events, while the active index is set on
><ButtonRelease-1>.
That's exactly what I wrote. But by writing, that it doesn't have much sense
to me I was going to say, that it seems to be misfunctionality - rather than
to say it doesn't follow "wired" events order.
> This has always been this way, and not only in Tk,
> but in other GUI frameworks, too.
So...?
The "active index" is the one, which I'm setting at the moment: either
using keyboard, or with mouse (can be with command too). If - at the same
moment - I'm not getting, what I'm expecting, there's something wrong. And
because of this one can't rely on "active" index, not being sure, whether
operator will be using keyboard, or mouse.
IMHO the result should be the same, and independent from the pointing device
being used. Otherwise: what's the point of detecting "active" index?
--
ZB
Bryan Oakley
> Dnia 11.06.2009 Csaba Nemethi <csaba.neme...@t-online.de> napisa³/a:
>
> > Think a bit more about it, and you will see that it is not right to
> > state that "it doesn't make any sense". Changes in the selection are
> > handled on <Button-1> events, while the active index is set on
> ><ButtonRelease-1>.
>
> That's exactly what I wrote. But by writing, that it doesn't have much sense
> to me I was going to say, that it seems to be misfunctionality - rather than
> to say it doesn't follow "wired" events order.
>
> > This has always been this way, and not only in Tk,
> > but in other GUI frameworks, too.
>
> So...?
>
> The "active index" is the one, which I'm setting at the moment: either
> using keyboard, or with mouse (can be with command too).
What you wrote is hard to parse because the term "moment" is a bit
imprecise. At the moment you press the mouse button you are setting
the selection but not necessarily the active index. When you release
the mouse button you are setting the active index but not necessarily
the selection. These two indices -- the selection and of the active
index -- represent two different things.
> If - at the same
> moment - I'm not getting, what I'm expecting, there's something wrong. And
> because of this one can't rely on "active" index, not being sure, whether
> operator will be using keyboard, or mouse.
What is wrong in this scenario is your expectation. Tk is working as
documented, you're just failing to understand the documentation. Of
course, that could mean the documentation isn't as good as it could
be. Perhaps you can offer some advice on how better to word it so
there's more of a distinction between "active" and "selected".
>
> IMHO the result should be the same, and independent from the pointing device
> being used. Otherwise: what's the point of detecting "active" index?
The point of detecting the active index is to distinguish between what
the selection is and what the, uh, active index is. Sometimes you need
both to be different, such as for extended selections.
MSEdit
> Dnia 11.06.2009 Csaba Nemethi <csaba.neme...@t-online.de> napisa³/a:
Why should the results be the same when you have two different
mechanisms, the active item is NOT always selected.
Try changing the activestyle to box or underline you can easily change
it with the keyboard but the selection can be elsewhere.
I seem to remember that only one item can be active but several can be
selected.
Martyn
ZB
> What you wrote is hard to parse because the term "moment" is a bit
> imprecise. At the moment you press the mouse button you are setting
> the selection but not necessarily the active index. When you release
> the mouse button you are setting the active index but not necessarily
> the selection. These two indices -- the selection and of the active
> index -- represent two different things.
OK, so shouldn't there be assumption taken, that as "active" we understand
(index of) exactly that element, whose selection state is currently being
changed - either using mouse, or keyboard, or with command?
That's my understanding of "active" term, something like: "the list element,
that we are doing something to". And not necessarily "the one formerly marked
with dotted box (or underline)". The latter one can be pretty inactive since
longer time.
--
ZB
ZB
> Why should the results be the same when you have two different
> mechanisms, the active item is NOT always selected.
What I mean, is: "item currently being (de)selected we're calling `active' ".
The ones, we don't touch - are inactive ones.
--
ZB
Bryan Oakley
> Dnia 11.06.2009 Bryan Oakley <oak...@bardo.clearlight.com> napisa³/a:
>
> > What you wrote is hard to parse because the term "moment" is a bit
> > imprecise. At the moment you press the mouse button you are setting
> > the selection but not necessarily the active index. When you release
> > the mouse button you are setting the active index but not necessarily
> > the selection. These two indices -- the selection and of the active
> > index -- represent two different things.
>
> OK, so shouldn't there be assumption taken, that as "active" we understand
> (index of) exactly that element, whose selection state is currently being
> changed - either using mouse, or keyboard, or with command?
No, that assumption should not be taken.
Bruce Hartweg
you can have a 'ZB' definition of "active/inactive" but it is NOT
what active/inactive means to the Tk listbox. It has a different
meaning, different behavior and reasons for them (and it is documented).
Instead of trying to change it you need to learn and understand it
so you can use it properly. If you want the selection you need to
get the selection, not the active index. and even though your initial
report said it always returned the former selection that was only because
of the way you were doing things, that exact same code could return the current
selection, the former selection, an item from 7 selection changes past, another
item the has never been selected, etc.
Bruce
ZB
>> What I mean, is: "item currently being (de)selected we're calling `active' ".
>>
>> The ones, we don't touch - are inactive ones.
>
> you can have a 'ZB' definition of "active/inactive" but it is NOT
> what active/inactive means to the Tk listbox. It has a different
> meaning, different behavior and reasons for them (and it is documented).
Oh, yes:
#v+
active
Indicates the element that has the location cursor.
[..]
In extended mode the new active element becomes the selection anchor
#v-
While not much about "behavior and reasons", but it all seems to be just
matter of specific TCL's terminology, as I see (like "one-dimensional
array" = "list" etc.)
--
ZB