Yes, I understand that you are just trying to place the tooltips in the correct location. That app demonstrates positioning tooltips, but happens to take things further by creating them itself and place them in external windows. My intention was to show that it is possible to have some say over how a tooltip is displayed without having to modify core Pivot classes.
On 24 July 2011 08:24, Bill van Melle <[email protected]> wrote: > The problem with tooltips is not their being confined to the window, but the > coordinates at which they are launched. > > I suspect I've gotten as far as I can get without editing the Pivot sources > (and as you saw, I did suggest an edit to the sources to get tooltip > placement). There are lots of controls I haven't even looked at yet, but > I'm guessing the main issue is that there are controls (such as ListButton) > that render stuff directly onto the window at the top of the display > hierarchy, with no knowledge of any transforms in between. I think to make > them work right with ScalePane, they would at a minimum have to do something > in addition to my (updated) mapPointToAncestor, say a computeScaleAtAncestor > method that walks up the tree and takes into account any scale transforms on > the containers it passes. And in order to make use of whatever numbers a > control got back from computeScaleAtAncestor it would have to have a way of > scaling the thing it's displaying. Which means either a ScalePane sort of > container, or a ScaleDecorator that (as Greg muses earlier in this thread) > the control's mouse events take into account. Is that too close to the > extra complexity that Greg suggested Pivot was trying to avoid by not having > render transforms at the component level? > >
