Hi,
First, let me explain the setup:
The problem occurs whenever a height is explicitly set for submenu groups. It occurs both when it is set via each subgroup's GroupSettings.Height property (as I am doing), and when it is set via the DefaultGroupSettings-Height property.
What happens is, whenever the browser is shrunk so that the menus would run off the page, the menus are automatically shrunk so as to fit on the page and scrollbars are added. This is despite EnableAutoScroll and EnableScreenBoundaryDetection being false. If a height is not explicitly set, this does not occur, and the menus simply go off the screen as expected. What makes this issue worse is that if the browser is then enlarged so that the menus would no longer be going off the screen, the menus stay shrunk.
What's happening appears to be that, if and only if a height is explicitly assigned to a submenu group, some sort of screen boundary detection kicks in and resets the height of the menu so that it will fit on the screen. Next, because the height of the menu is now too small to fit all of the items, scroll bars are automatically added. When the browser window is then expanded, the height is never set back to what it originally was, and stays small with scroll bars.
I've attached a few images to show what I am talking about.
Is this indeed a bug? It seems like it can't possibly be the intended functionality (edge boundary detection is occurring and scroll bars are automatically being added despite both being told not to do so). Am I just missing some other parameter that would stop this from happening?
If this is a bug, is there any good way to work around this until it is fixed? I have attempted, amongst other things, to reset the height of the submenu group on the client side in the OnClientItemOpening event using eventArgs.get_item().get_groupSettings().set_height(), but it appears as if altering this value does not have any affect once the menu has been rendered. I've even gone so far as trying to work outside the API, using the eventArgs.get_item().get_element() function to access the actual DOM element, then using JavaScript to access the child DIV being used to represent the subgroup and manually setting its style element. However, with the way that items are dynamically added and removed to the page, this has proven unreliable.
Lastly, is there anywhere where I can access a complete client-side API? The best I've found in the help manuals is this page, which itself says it only has "the most important methods", and doesn't even contain things like item().get_groupSettings(). Further, I've seen in these help forums the use of other attributes, like item._slide, which as far as I can tell are undocumented.
I really appreciate any help you can provide!
Thanks,
Kevin
First, let me explain the setup:
- I am using the most recent 2011 version of Telerik Web.UI
- The page is being developed for IE7 (though the same error occurs in Firefox 3.6).
- In the code-behind, I am dynamically setting the OffsetY property of all GroupSettings objects so that all submenus fly-out at a consistent location (i.e., aligned with the top of the root menu, rather than lined up with the menu item that spawned them).
- I am dynamically setting the Height property as well, so that all submenus display at a consistent height.
- I have EnableAutoScroll and EnableScreenBoundaryDetection both set to false.
The problem occurs whenever a height is explicitly set for submenu groups. It occurs both when it is set via each subgroup's GroupSettings.Height property (as I am doing), and when it is set via the DefaultGroupSettings-Height property.
What happens is, whenever the browser is shrunk so that the menus would run off the page, the menus are automatically shrunk so as to fit on the page and scrollbars are added. This is despite EnableAutoScroll and EnableScreenBoundaryDetection being false. If a height is not explicitly set, this does not occur, and the menus simply go off the screen as expected. What makes this issue worse is that if the browser is then enlarged so that the menus would no longer be going off the screen, the menus stay shrunk.
What's happening appears to be that, if and only if a height is explicitly assigned to a submenu group, some sort of screen boundary detection kicks in and resets the height of the menu so that it will fit on the screen. Next, because the height of the menu is now too small to fit all of the items, scroll bars are automatically added. When the browser window is then expanded, the height is never set back to what it originally was, and stays small with scroll bars.
I've attached a few images to show what I am talking about.
Is this indeed a bug? It seems like it can't possibly be the intended functionality (edge boundary detection is occurring and scroll bars are automatically being added despite both being told not to do so). Am I just missing some other parameter that would stop this from happening?
If this is a bug, is there any good way to work around this until it is fixed? I have attempted, amongst other things, to reset the height of the submenu group on the client side in the OnClientItemOpening event using eventArgs.get_item().get_groupSettings().set_height(), but it appears as if altering this value does not have any affect once the menu has been rendered. I've even gone so far as trying to work outside the API, using the eventArgs.get_item().get_element() function to access the actual DOM element, then using JavaScript to access the child DIV being used to represent the subgroup and manually setting its style element. However, with the way that items are dynamically added and removed to the page, this has proven unreliable.
Lastly, is there anywhere where I can access a complete client-side API? The best I've found in the help manuals is this page, which itself says it only has "the most important methods", and doesn't even contain things like item().get_groupSettings(). Further, I've seen in these help forums the use of other attributes, like item._slide, which as far as I can tell are undocumented.
I really appreciate any help you can provide!
Thanks,
Kevin