I can see within the samples that are included with the ASP.Net 2010 v1 that if the urls within the items target an iframe on the same page that the user can always be reminded of what page they are on, aside from the page contents and url, by glancing at the currently selected item in the WebExplorerBar.I currently use a simmilar control(ASPxNavBar) within a DevExpress suite. Placed within a master page scenario, populated by a sitemap, it always shows the line from the sitemap as selected when on that sitemap entry page, without additional programming. I would like to begin migrating my controls over to Infragistics controls, but implimented the same way, the Infragistics WebExplorerBar does not show the currently visited page as selected. Is there a property I need to manipulate? If this functionality is not built in, is there a way for the WebExplorerBar to programaticlly examine the URL and determine if the url matches an "Item", and if so, make that item show as selected, just as it does within the iframes based sample?
I am having the same problem. Did you find a solution to this problem?
No, I have not. Until I can figure out how to get the Infragistics control to keep it's behavior when inside of a master page like the DevExpress control does, I'll keep using the free DevExpress control.
Can you elaborate a little bit what problems do you have with ExplorerBar in a master page?
Thank you very much for your attention on this issue.
I see you point and agree with you. I'll make sure this is resolved in a future release.
Many of the pages in our website have codebehind that is depenant on things such as querystring parameters. Additionally, these pages are navigated to from other applications with a known convention of querystring parameters. While I could pass querystrings to pages within an iFrame while users are navigating within the app, I predict it would be an administrative nightmare to try to create a “host” page for every page in the solution so that parameters in the browsers URL can get pulled to the page within the iFrame. This is why I don’t believe I can migrate from my master page design to using a single aspx page, loading all others within an iFrame(which is what it sounds like I would need to do to show “selection”. Although the WebExplorerBar is arguably more powerful, for this type of navigational implimentation, the ASPxNavBar looks and operates simillarly to the WebExplorerBar. What is so nice about the ASPxNavBar is, all I have to do is plop it into the div on the left side, within a master page content area, point it to a sitemap file and viola, the ASPxNavBar shows the corrosponding entry in the menu that the user sees as selected, based on whatever the current page is(as long as there is, in fact of course, a corrosponding exact match within the sitemap file). 100% automatic and astheticlly helpful to the users.
With all due respect, I would disagree with your statement that “...the only scenario this is useful is if the user opened the URL by writing it directly to the browser, or through a bookmark.” Nearly every user I’ve polled has appreciated the fact that the navigational component they are using shows them which page they are on, even when they are navigating through the site, not just having been redirected to it from outside the app or from a bookmark. If I go to Infragistics.com, select “Products”, “Windows Forms Controls”, I am taken to a page that has a menu on the left, consisting of “Overview”(the default landing page, HIGHLIGHTED in blue), “New Features”, “Downloads”, & “Roadmap”. If I select “New Features”, “Overview” turns white and “New Features” turns blue. Your own website 100% proves my point for me and contradicts your opinion. We could argue that that specific menu on the Infragistics page is being driven by a control other than the WebExplorerBar, but if Infragistics is going to advertise that the WebExplorerBar is well suited for site navigation, utilizing a sitemap as it’s source, then I would see very little room for argument against the case that such simple manipulation of text color(again, as demonstrated on Infragistics.com) should be a standard feature, not something the user(me) has to write javascript to achieve.