Table of Contents
  • Getting Started
  • EO.Pdf
  • EO.Web
    • Overview
    • Installation & Deployement
    • EO.Web ToolTip
    • EO.Web Rating
    • EO.Web Slider & RangeSlider
    • EO.Web ListBox
    • EO.Web ComboBox
    • EO.Web Captcha
    • EO.Web ASPX To PDF
    • EO.Web Slide
    • EO.Web Flyout
    • EO.Web EditableLabel
    • EO.Web ImageZoom
    • EO.Web Floater
    • EO.Web Downloader
    • EO.Web ColorPicker
    • EO.Web HTML Editor
    • EO.Web File Explorer
    • EO.Web SpellChecker
    • EO.Web Grid
    • EO.Web MaskedEdit
    • EO.Web Splitter
    • EO.Web Menu
    • EO.Web Slide Menu
    • EO.Web TabStrip
    • EO.Web TreeView
    • EO.Web Calendar
    • EO.Web Callback
    • EO.Web MultiPage
    • EO.Web Dialog
    • EO.Web AJAXUploader
    • EO.Web ProgressBar - Free!
    • EO.Web ToolBar - Free!
  • EO.WebBrowser
  • EO.Wpf
  • Common Topics
  • Reference
Table of Contents
Using Cross Frame Menu - without a single line of coding

Apply to

Menu, SlideMenu

Set TargetFrame property - That's it!

EO.Web Menu and SlideMenu support cross frame without requiring a single line of coding. To create a cross frame menu, simply set the menu's TargetFrame property to the name of the frame in which all sub menus should appear.

The rest of this topic covers several details about cross frame menus.

Styles & images are automatically handled

Event Handling & NavigateUrl

Cross domain security

When target document is not a HTML file

Styles & images are automatically handled

All styles used by the menu will be automatically rendered into both the master frame and the target frame. If you use CSS class, make sure you also set the CssFile property. CssFile property, once set, will also be rendered into the target frame.

Try to always use ImageBaseDirectory or "~/" when using images in cross frame menu. When ImageBaseDirectory is used, relative image Urls used by the menu are being combined with ImageBaseDirectory and then translated into absolute path. This feature is especially useful with cross frame menu as some images may be rendered into the target frame. For relative Urls within the target frame, browsers evaluate relative path based on the current page of the target frame, which may not be desired.

For example, if the master menu resides in "/Index.aspx", where the target frame is "/Docs/Contents.html", within the target frame, a relative path "Images/Item1.gif" will be translated into "/Docs/Images/Item1.gif" instead of "/Images/Item1.gif". Using ImageBaseDirectory or "~/" (which represents the Web application root) will causes EO.Web Menu automatically translate relative image path into absolute image path before rendering to the client.

Due to some limitation of the Apple Safari browser, styles cannot be automatically injected into the target frame on this browser. Sub menu will still be created and displayed in the target frame.

Event Handling & NavigateUrl

All event handlers are called in the context of the original frame as if the menu were not using cross-frame. For example, if you have a menu in Banner.aspx and TargetFrame.html in the target frame, and you wish to handle navigation item click event on the client side, you should write an ClientSideOnItemClick handler in Banner.aspx, not in TargetFrame.html, regardless whether the navigation item clicked is actually rendered in Banner.aspx or in the target frame.

This completely eliminates the need to modify the target frame -- which is especially convenient when you do not have control over the target frame's source code. This also means that there is no special requirement on the page loaded in the target frame, as long as it is standard HTML page.

NavigateUrl automatically targets the target frame when used in a cross frame context. To force it to target other frames or the hosting frame, you should explicitly set the TargetWindow property to the name of the frame in which you want NavigateUrl to be loaded.

Cross domain security

For security concerns, all modern browsers applies certain restrictions on DTHML object model when using cross domain scripting. For this reason, contents for the master frame and the target frame must be from the same domain. Pointing them to different domain will cause access denied script error.

A possible workaround is to use iFrame. Instead of setting the source file directly on the content frame, you can let the content frame to host an iFrame and set the source file on that iFrame. For example, instead of using:

HTML
Copy 
<framset>
   <frame src="topmenu.aspx">
   <frame src="someothersite.com/some_page.html">
</frameset>

Try use:

HTML
Copy 
<framset>
   <frame src="topmenu.aspx">
   <frame src="contentpage.html">
</frameset>

And contentpage.html would be:

HTML
Copy 
<body>
   <iframe src="someothersite.com/some_page.html">
</body>
You can also change contentpage.html to an ASP.NET page so that you can use ASP.NET rendering syntax to dynamically set the target page for the iFrame element:
HTML
Copy 
<framset>
   <frame src="topmenu.aspx">
   <frame src="contentpage.aspx">
</frameset>
And contentpage.aspx would be:
ASPX
Copy 
....
<body>
   <iframe src="<%=GetIFrameSource()%>">
</body>
Where GetIFrameSource is a protected function of your page class:
Copy 
Protected Function GetIFrameSource()
   GetIFrameSource = "some_url"
End Function

When target document is not a HTML file

EO.Web Menu/SlideMenu uses DHTML object model exposed by target frame's document to create sub menus inside the target frame. This will not work if the document inside the target frame is not an HTML document. For example, if the document in the target frame is a .pdf file, EO.Web Menu will not be able to create sub menu inside the target frame.

To solve this problem, you can use the same technique as described in "Cross domain security" section: use a regular HTML page to host an iframe, then use that iframe to host the non-HTML document.