Hi,
We're using the 2008.1 release and have run into a problem where the positioning of the Popup Menu, when attached to the a Tree View, is incorrect. With a bit of analysis we can see that in Internet Explorer, the issue is due to the fact that the position is not taking into account the top and left margins of the page - we have a fixed margin of 10px at the top of the page and are using 'Margin: 0px auto 0px auto' to achieve centering. There are also problems in Firefox, but at the moment we have not understood the cause, however the positioning is more significantly incorrect and every time the popup menu is displayed by right clicking on the tree node it's width increases by a number of pixels.
Has anyone else experienced this issue? Is there something that we should be doing, but have missed?
For reference, we use the javascript below in other solutions to position popup help panels, etc for a given element successfully in both Firefox and Internet Explorer.
function FindElementsPosition(element) {
var curLeft = 0; var curTop = 0;
if (element.offsetParent) {
curLeft = element.offsetLeft curTop = element.offsetTop
while (element = element.offsetParent) { curLeft += element.offsetLeft curTop += element.offsetTop }
}
return [curLeft,curTop];
Thanks in advance....
Cheers, James.
Hello James,
Positioning in browsers is a very tricky topic, and there are various problems to deal with. The FindElementsPosition function you are using is a variation of the classic FindPos function first introduced by the Quirksmode web-site:
http://www.quirksmode.org/js/findpos.html
However, If you are already using ASP.NET 3.5 and/or ASP.NET AJAX, you can try using the not very popular, but very helpful client-side method getLocation to get the coordinates of the element clicked and place the menu there. Some information can be found here:
http://weblogs.asp.net/bleroy/archive/2008/01/29/getting-absolute-coordinates-from-a-dom-element.aspx
I am almost positive that the newly introduced function gives better results than the QuirksMode one. You can also take a look at the following blog post for comments/reflections and suggestions related to positioning and coordinates in browsers:
http://www.jtulloch.com/blog/post/2008/02/Mouse-position---relative-to-a-containing-element.aspx
Hope this helps.
Hi Rumen,
Thanks for the response, we are indeed familiar with the articles you've provided links to above. I guess the question we're asking, is should we be expecting the Popup Menu functionality to work correctly 'out of the box'? We can see that it works in the samples and the demonstration sites provided, but seems to fall down when margins are involved. Our development plans for the project asssume that the Infragistics toolkit provides the functionality we require as advertised and haven't considered at this stage that we need to be responsible for actually resolving positioning issues related in this case to Popup Menus attached to the UltraWebTree.
We need a steer as to whether we need to factor in this development into our schedule, or should be raising this as a bug with Infragistics. As far as the examples and documentation indicate, unless we are missing something, we should only need to add the following to achieve the functionality required;
if(button == 2) { var tree = igtree_getTreeById(treeId); igmenu_showMenu('UltraWebMenu1',tree.event) return true;}
I look forward to hearing from you.....
Yes, I see your point, igmenu_showMenu should indeed be able to resolve the positioning correctly in all cases without the need for developers to do that with tricky javascript code.
I agree with you that this is most probably something we need to introduce in our own code and this is most probably an issue in UltraWebMenu - it does not always position the popup correctly in all cases.
I created a bug report (BR31710) and added you as a person to notify when progress status for this bug has changed and I will personally make sure this is addressed asap.
Any additional comments/suggestions are as usual welcome.
Thanks for the sample project - it will be much easier for us to verify the expected results this way and add your specific scenario to our automated test suite. We can probably address that soon enough, problem is that our next HotFix is scheduled for April, 4th (just a couple a days till then) and the fix will most probably not make it in this hotfix.
I will talk to PM and let you know when we can have this for sure.
Thanks Rumen,
I've put together a project that demonstrates the issue and attached it to this post - so that we have a common reference. When do you envisgage that your development team will be able to look into this issue and advise on any workarounds and/or resolution timeframes? I need to feed this back into our development schedule and see if this is manageable or we need to seek alternative solutions to achieve the delivery targets.