I am not sure if WebDataMenu was a new control in v11.1, but it seems really buggy.
I added 4 root menu items and made the third root menu item have 2 child menu items. The 4th item does not show up - there seems to be space for it, but hovering or clicking does nothing and the words for the menu item do appear to show up at all.
Also when I try to reduce the font using the webdatamenu property Font-size, the any of the other CssClass properties available at different levels, the font size (and also color) do not change.
Additionally I wanted to change the height of the menu "bar" and this did shrink to the appropriate size, but the text stayed in the same position it was in before and I could find no way to get it to shift so that it was no longer partially "cut off". Also there is now a "gap" between the 3rd root menu item and its children.
Any help with this would be much appreciated.
Hello Greg,
I have heard back from the Engineering team that the WebDataMenu minimum height is 26 pixels. If you set the menu height to 18px directly in its settings its height will be still 26 pixels, but only 18px will be visible. If it’s set in the GroupSettings the menu will keep its minimum height (26px). This is because WDM items have default padding on which base is calculated their height. I have attached the Markup for demonstrating the same.
The work around is to override the root menu padding like this:
.igdm_MenuItemHorizontalRoot
{
padding: 2px 4px;
}
The result is WDM with height exactly 18px.
Please let me know if you have any further questions regarding this matter.
Thank you for looking into this. I will have to look at what you have regarding the missing fourth item in the menu. Did you happen to look at the Sandbox example I attached in the OP? It had all the issues I mentioned. I had the problem in that sample which is as basic as it gets.
As to the other issues. You mention editting the weddatamenu.css directly. Where might I find that and how might I include that in my project so that the each other developers will not have to make this change, too? Also will I have to overwrite this css each time we get a new version of Infragistics?
I have opened a support request for this forum post so we may research this behavior further. Please use the following link to log onto your account at Infragistics.Com:
<https://ko.infragistics.com/Membership/MySupport.aspx>
Once you are logged onto your account, go to My Support Activity to view the progress of this support request. An update will be sent to you in the support request with any new information we find.
Please let me know if you have any questions.
Hi Prabha,
Will you be posting any resolution on this thread as well (better than opening a ticket for everyone who views this thread).
We've run into the same disappearing menu item issue (#1 on the original post), and our edits of ig_datamenu.css (.igdm_ClaymationMenuItemHorizontalRootLink, in our case) have not resolved the issue for us.
Charles
Hello Charles,
I will update this forum thread once there is a resolution for the missing item.
Let me know if you would like me to notify you once this is resolved. I will create a case for you and link it to development issue.
After a *lot* of experimentation, I think I see what is happening.
It seems that the menu calculates what size it should be and then, depending on font size and weight, renders what will fit in that box, cutting off anything that won't fit.
My setup: I'm using StyleSetName="Claymation", and I've been modifying ig_datamenu.css. In my case, the class that is causing the problem turns out to be .igdm_ClaymationControlHorizontal a:link, .igdm_ClaymationControlHorizontal :visited (because of settings in .igdm_ClaymationControlHorizontal -- including overflow: hidden;).
The CSS class consists of:
font-family:Verdana,Arial,Lucida Grande,Lucida Sans Unicode,Lucida,Helvetica,Sans-serif; font-size: 10px; font-weight: bold; color: #ffffff;
With this font size and weight, all the elements of the menu display (depending on the user type, one of two menus can display, one considerably shorter than the other). Also, the full menu displays if I comment out the weight or change it to font-weight: inherit.
However, as I increase the font size, more and more items get removed from the right-hand side of the menu (the only time nothing gets lost is for size = 10px or size = inherit). Eyeballing both the shorter and longer menus, I can approximate where the cutoff point will be, and that point is different for the two menus, supporting my conjecture that an internal calculation is done for each menu, not that there is some absolute cutoff point.
The easiest way to attempt to replicate this is to focus on the font size rather than the font weight, as using the size is obviously easier to increase/decrease the overall size of the menu.
HTH,
As a follow-up to my previous post:
Found a solution: http://codecorner.galanter.net/2012/12/28/infragistics-webdatamenu-last-item-disappears/
What if I do need my menu to scroll? My horizontal menu is limited by certain width, and the items are added to it in server-side code at runtime. So when there're more items than menu can fit, I need it to scroll. And it works - it scrolls and all items appear correctly - in all browsers but FireFox. In FireFox last item is always missing.
Any idea how to make this work with scrolling enabled? thanks
Thanks, Prabha, that did the trick.
For others reading this thread, EnableScrolling is a WebDataMenu property, not some obscure CSS tag.
I heard back from development team that setting Enablescrolling property to false will resolve the issue of missing item. By default this property is true.
Setting EnableScrolling to true will result to fixed width of the <ul> element which holds all the root menu items. The problem comes when there is bold style applied to the menu container, because in the calculation of the <ul> element width is not taken.