Tooltips for headers in TkTreectrl?
in [TCL]
|
From: Jeremy on 18 Jan 2010 14:23 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. How can I bind an event to realize that the mouse is over a header item in TkTreectrl? Thanks for any help, Jeremy
From: Tim Baker on 18 Jan 2010 15:23 You are doing it the only way it can be done. The treectrl.tcl library 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... > 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. > > How can I bind an event to realize that the mouse is over a header > item in TkTreectrl?
From: Arnold Snarb on 18 Jan 2010 17:32 Jeremy spoke in class today: > > 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
From: Jeremy on 18 Jan 2010 19:12 On Jan 18, 5:32 pm, Arnold Snarb <asn...(a)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. 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
From: Donal K. Fellows on 24 Jan 2010 04:18
On 19/01/2010 00:12, Jeremy wrote: > 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. |