Tooltips for headers in TkTreectrl?
Jeremy
when the mouse is over a header item in TkTreectrl except respond to
the Motion event and call identify all the time. This seems to be a
bit excessive to call identify each time the mouse moves.
How can I bind an event to realize that the mouse is over a header
item in TkTreectrl?
Thanks for any help,
Jeremy
Tim Baker
script does
it the same way when tracking the mouse (for example to change the cursor
at the edges of the column headers to allow resizing).
-- Tim Baker
"Jeremy" wrote...
Arnold Snarb
>
> I know how to accomplish a tooltip, but I do not know how to realize
> when the mouse is over a header item in TkTreectrl except respond to
> the Motion event and call identify all the time. This seems to be a
> bit excessive to call identify each time the mouse moves.
If you need to identify where the mouse is whenever it moves,
then you need to identify where the mouse is whenever it moves.
Responding to a <Motion> event and calling [$tcw identify]
is the way you do that.
Why does this "seem a bit excessive"?
Is it too slow?
Is it *actually* too slow, or is it just something that you
guess might be like the kind of thing that seems like it might
probably maybe be too slow, perhaps?
--Arnold
Jeremy
>
> Why does this "seem a bit excessive"?
>
Because the only reason I need to do it is to show a tool tip when the
mouse is over the header. 99.99999% of it's entire life and after the
application has been used for a short duration, the tooltips will no
longer be useful. The header takes up about 1/20th of the area that I
will have to check identify on each time. It would seem better to be
able to identify where the header is at and only call more costly
functions when the mouse is in that area.
> Is it too slow?
>
> Is it *actually* too slow, or is it just something that you
> guess might be like the kind of thing that seems like it might
> probably maybe be too slow, perhaps?
>
Not on my machine however, on some clients computers some areas of the
GUI are already sluggish and I didn't want to risk adding more heavy
weight items with little benefit, i.e. what I stated above about
tooltips only being used initially to learn the interface.
Jeremy
Donal K. Fellows
> Because the only reason I need to do it is to show a tool tip when the
> mouse is over the header. 99.99999% of it's entire life and after the
> application has been used for a short duration, the tooltips will no
> longer be useful. The header takes up about 1/20th of the area that I
> will have to check identify on each time. It would seem better to be
> able to identify where the header is at and only call more costly
> functions when the mouse is in that area.
I don't know whether this is still useful to you, but the most useful
way of handling this is to add a bit of delay to the proceedings. On a
<Motion>, don't do anything until a short while after the mouse has
stopped moving ([after] and [after cancel] make this easy to code). You
only need to identify where you are when the user pauses of a part of
the widget. A few hundred milliseconds (you'll need to tune it) will be
hardly noticeable to the puzzled user, but will avoid expensive things
when not needed.
Donal.
Donald Arseneau
> On Jan 18, 5:32 pm, Arnold Snarb <asn...@fdip.bad-monkeys.org> wrote:
> > Why does this "seem a bit excessive"?
>
> Because the only reason I need to do it is to show a tool tip when the
> mouse is over the header. 99.99999% of it's entire life and after the
> application has been used for a short duration, the tooltips will no
> longer be useful.
Is there something about tktreectrl that eliminates <Enter>
and <Leave> events?