This issue seems to be related to IE 6. We all hate IE6 but several corporations have drive images that use this version for their entire corporate infrastructure. That being said. It must work in IE6.
We have several controls on a page, a Panel containing a chart and an ultrawebgrid below it. When the chart takes up most of the window, the tooltips over the columns show correctly. But when scrolling down to the bottom of the page (to look at the web grid).. If one were to scroll over the still visible chart above.. The tooltips now show over the webgrid instead.
In other words, the location of the tooltip seems to be relative to the bottom of the window, not the actual chart. It appears to be about 300 pixels away from the actual cursor. In firefox, the tooltip always displays next to the cursor (which is expected).. In IE, the tooltip seems to be different based on where in the page you happen to be scrolled.
Is there a way to over-ride or fix this behavior??
We fixed this issue recently. Try applying the latest service release.
This is a major issue for me.
I upgraded my project to 20092.2025 (your latest service release)
The issue is in IE7 - the tooltips appear in the correct location UNTIL I scroll down my page - once I scroll down the tooltip appears far BELOW the chart.
Scrolling down further results in tooltips "appearing" way below the page content. (the scroll bar shows the page getting much longer)
I dynamically add WebUserControls to and asp:Panel to build my page content.
The WebUserControls each have one UltraChart on them.
Try getting:
Yes, the latest SR doies fix this. Thanks!
(I downloaded 2025 - just days before 2056 was available :)
I’ve just asked and it seems that the name of the last SR was wrong (the name is changed already). It contains the .NET CLR 3.5 version too.
Can you try downloading the latest SR from:
http://es.infragistics.com/dotnet/netadvantage/aspnet.aspx#Downloads
and tell us, if your issue still exists.
I’m sorry about all misunderstandings.
I tried this version, albeit I require .NET CLR 3.5, and it was definitekly not fixed in the latest service release.
Shouldn't the fix in CLR2.0 also be in the CLR3.5 release?