Support for tooltips in treelist

[ArmstrongJ]

This commit brings tooltips to the Treelist control in a pretty simple manner.

[mity]

Jeff, I won't merge this. I would like to have it much closer to what std. list-view and tree-view provide. Consider these arguments:

• 99% of apps don't want to set tooltips explicitly. They just want the std. behavior, i.e. to popup-up a tooltip with the item text when the control/column is too small to show it completely and mouse hovers over it.
• I am very reluctant to make treelist_item_t larger, especially with respect to the above. Tree(list) control is designed to manage big number of items in a visually reasonable way. Even relatively shallow trees can have a lot of items. A tree with 10 roots, each having 10 children, each having 10 children, etc.. gets you easily to 111.110 items on 5th level. Every saved byte in this structure is worth of gold. It is already much larger then I would like to.
• The std. controls do "the right thing" for 99% of apps. The remaining 1% can override tooltip text via LVN_GETINFOTIP or TVN_GETINFOTIP notification.
• Last but not least, app. developers are used to deal with the way how std. controls do it. This control is modeled after list-view and tree-view. I argue the API should too, until there is strong reason to do differently in a particular case. I cannot see any in this case.

Yes, that's a lot of more work. But IMO, that's the right way.

As a side note, I would like to reach 1.0 in a foreseeable future (few months) and that will start the "no ABI breakage" policy. That means that then any new members in public structs (like pszTooltip in MC_TLITEMW) should be introduced as the last ones to not break older apps.

[ArmstrongJ]

Well, I wish you had mentioned this when I had mentioned tooltips earlier, but that's fine. The treeview/listview method was, IMHO, a better way to go. I was just attempting to conform to how it's handled in the chart control. Stripping out the tooltip code is trivial.

[mity]

Well, I was not aware when and how you want to implement it. I expressed my view on importance of the consistency so I expected you take a look how the std. controls do it before you start. I also expressed some worries how much of the code can be shared with chart. That could make bells in your head ring that perhaps I might see the tooltips in these controls as two different things.

Note I will always be very careful about patches with impact on the public interface. Any such change will have to be maintained for a long time with respect to compatibility. Doing this right is more important then the implementation. Broken interfaces are much harder to fix without breaking apps.

That's one of the reasons I try to follow the std. controls. Their interface is known to work. It is tested for years by so many apps out there. Every time I consider adding a feature into mCtrl I start by studying MSDN how COMCTL32.DLL and USER32.DLL controls do the similar things (both from user point of view as well as from app. developer point of view) and then think whether they are appropriate for my control.

Whenever unsure, feel free to open an issue here on github, or reach me with e-mail (see Readme file) in advance before you start coding and we can discuss things.

All that said, I want to state very clearly that changes from the std. controls are acceptable. But you must be able to convince me by providing arguments why the other way is required or superior.

BTW, the tooltip in chart is different by definition from tree-list view. It serves different purpose. And it has its counterpart in COMCTL32.DLL too: See http://tdwiki.daverabelink.net/images/4/42/TrackbarSample.jpg