Javascript bug? Naming onclick event handlers in EBMM?

[Dr Paul A Daniels]

I don't know if it helps but I spotted what may be a typo in function ebmDisplaySubmenu. At about character 1025 there's the following code:

Code: Select all

...if(isMz)m.style.magrinRight=20...

[/color]

Should 'magrin' be 'margin'?
<hr>

I want my buttons/submenu items to load a static HTML page into an ID'd <div> area. How do I nominate my Javascript onclick event handler functions within EBMM? I use the %IncFile pre-processor function to update my buttons/menus within my page so that I can keep everything nice 'n modular. If I have to doctor the HTML/Javascript output from EBMM everytime then that's a real .

[Karlis]

Will take a look.

[Dr Paul A Daniels]

I want my buttons/submenu items to load a static HTML page into an ID'd <div> area. How do I nominate my Javascript onclick event handler functions within EBMM? I use the %IncFile pre-processor function to update my buttons/menus within my page so that I can keep everything nice 'n modular. If I have to doctor the HTML/Javascript output from EBMM everytime then that's a real .

I figured out a way to solve the problem! Links typed into EBMM appear in the output HTML as href="LinkText" where LinkText might be something like /MyFolder/MyPage.htm#MySection. I needed to open the linked documents in an IFRAME with an ID of, say, MyClient. To do this I entered the following link into EBMM:

/MyFolder/MyPage.htm#MySection" target="MyClient

Note the two double-quotes: one after my original link and one after the target=.

When EBMM outputs this to the HTML it wraps the entire thing in double-quotes and so embeds the name of the target frame. This works for both buttons and submenu items, no additional JavaScript is required and no modification of the EBMM-generated HTML or JavaScript is required. This keeps the menu's built modular.

Perhaps, Karlis, as well as a link field in EBMM we could have a target field too so that this workaround isn't necessary?

I hope this helps some of you.

[Dr Paul A Daniels]

I figured out a way to solve the problem!...

Er, it appears I 'spoke' too soon .

I discovered that it works perfectly within WeBuilder 2007 (v8.31) but not properly using IE7 (either using a local IIS or by uploading to my web-site) and I can't get it to work at all with Firefox 2.

With WeBuilder both the buttons and submenu items correctly load the new page into the ID'd IFRAME area.

With IE7 the buttons are OK and correctly load the button's target as a new page into the ID'd IFRAME area but the submenu items insist on loading into the full browser window.

With FF2 neither the buttons nor the submenu items will load anything into the IFRAME area.

Any ideas what I might be doing wrong?

[Dr Paul A Daniels]

OK, I think I've got it sorted now but, unfortunately, it does require a small modification to the EBMM-generated JavaScript file that will have to be made everytime the menu is re-generated by EBMM.

Find the following piece of code in function ebmGenerateTree:

Code: Select all

p.onclick=function(){window.location.href=this.rowClickLink}

and change it to:

Code: Select all

p.onclick=function(){window.frames['Client'].src=this.rowClickLink}

where, in my case, 'Client' is the ID of the IFRAME I wanted to use as my target. Selecting menu items now opens the new page within the IFRAME; this approach is, of course, restricted to just one IFRAME. Perhaps a future ability to optionally associate a target with each button/menuitem would be possible?

Incidentally, the problem with FF was because I'd set the z-index of the IFRAME to be -1 so that the menus would open above it. Removing that z-index and, instead, setting the z-index of my DIV containing the menu buttons to 10 (or some other large number) cured the problem.

Everything now works as I wanted but it would be nice if there were some better way to use the buttons to perform tasks other than just loading a new page into the full browser window. Given that so many web-pages now use Ajax techniques to do so many things it would be nice if there were more 'hooks' into the button/submenu click (and other?) events.

[Aivars]

The next version (which is almost finished by now) includes functionality that allows specifying link targets. That should solve the problem.