Overflow scrollbar concern...

Poster: brettzamora
Dated: Thursday October 23 2003 - 18:36:41 BST

I am using V5RC6 and I have the overflow value for the menu set to scroll. I'm using the scroll feature on a website that I have up and running and it works fine with long menus. When the submenu has many items on it, the scroll bar appears on the right.

I'm working on another website right now with the V5RC6 version and when there are too many items on the list, I am seeing a scrollbar on the right AND on the bottom. I've increased the width of the submenu and it gets wider and wider, but the bottom scrollbar does not go away.

Any thoughts on how to prevent the bottom horizontal scrollbar from appearing? Thanks!

Poster: kevin3442
Dated: Thursday October 23 2003 - 18:41:01 BST

Hi Brett,

Are you sure you mean RC6 (you typed it that way twice, so I figure it wasn't a typo for RC16, but I thought I'd ask anyway)? If you are using RC6, first thing I'd suggest is update to RC17 and see if that helps.

Kevin.

Downloaded V5RC17... having problems

Poster: brettzamora
Dated: Thursday October 23 2003 - 19:22:54 BST

Hi Kevin...

Thanks for the quick response. I downloaded V5RC17 and followed my usual process for updating the objects in my website (development), which is to review the readme's then I overlaid the previous milonic_src.js, mmenudom.js, and mmenuns4.js objects. I edited the milonic_src.js file and assigned my scriptpath variable to ./javascript/. Now when I try to bring up my website, I get the generic javascript error that says a runtime error has occurred on Line 17 - object expected. None of my menus will display.

Did something drastic change in the menu code??

If you look at http://ecg.zware.net you will see that the menus are working fine with V5RC6.

I've seen this type of problem occur when parameters that used to be supported are dropped or in some cases when the parameters are simply changed. For example, the text at the Milonic website says in the QuickStart for the menus that the overflow parameter should be set to a value of overflow to cause scroll bars to appear. I wondered why that did not say set the value to scroll. (the value overflow does nothing, the value scroll does).

In any case, I can't tell if V5RC17 will solve my original issue and eliminate the horizontal scrollbar if V5RC17 won't even display my menus.

Your assistance is appreciated. Thanks!

Second issue resolved...

Poster: brettzamora
Dated: Thursday October 23 2003 - 20:14:24 BST

Okay... I traced down the issue regarding not being able to run the current version of the menu. In the V5RC6 release, there was not a requirement for me to load mmenudom.js or mmenuns4.js. (Or at least not explicitly). My menus worked fine.

On the current version, I hard coded the statement to include mmenudom.js (I'm using IE6). All the menus came up fine.

I added the if(ns) logic, as copied directly out of the menu.htm sample that I downloaded from Milonic. Again, errors.

I modified the if(ns4) block and took out the string concatonation stuff that the guys at Milonic used and ended up with the following block.

<script language="JavaScript">
if(ns4)
_d.write("<script language=JavaScript src=.\/javascript\/mmenuns4.js type=text\/javascript><\/script>") ;
else
_d.write("<script language=JavaScript src=.\/javascript\/mmenudom.js type=text\/javascript><\/script>") ;
</script>

The current menus seem to work fine now, however I'm noticing the following idiosynchrosies:

1. The scrollbars that I was previously concerned about don't even display now. Instead the code seems to want to adjust my submenu window upward from the position that I emphatically specified I want it at. For me, I prefer that the program not make decisions like that for me. Instead give me a parameter I can set to say I want that feature. (In this case, I don't. I only want my vertical scrollbar.)

2. I am using a feature technique that Milonic showed in a sample, where hovering over a menu item causes text to be displayed in a box somewhere else on the screen. Now with the new menu, my submenu box size seems to be reduced (or moved), by a couple of pixels in my IE6 browser. This condition does not occur in NS7.

I'm starting to think I better count my blessings and go back to RC6 and just accept the horizontal scrollbar. It seems that upgrading takes a pretty significant testing/debugging effort which is a little frustrating.

Thanks... Brett

Moving forward...

Poster: brettzamora
Dated: Thursday October 23 2003 - 20:40:14 BST

Okay, I've bitten the bullet and upraded to V5RC17.

I resolved the issue of the text box not displaying properly by setting the value for the variable _subOffsetTop to -3.

Everything lines up fine in both IE6 and NS7.

I'm still bothered by the fact that the menu adjusts my submenu position upward. I don't want it moved up, but I suppose I'll just have to accept that so that I can use the current version.

This functionality could cause an issue for me on another site I've developed where the customer is emphatic about having the top of a vertical submenu line up with the menu item it is related to.

Anyway, I'm current again. My only comment now is that I wish we didn't have to worry about things that are working perfectly breaking or changing. IE, needing to make an adjustment to the _subOffsetTop variable value. Being forced to make a change like that means I have to go through and look at everything else in the site to ensure I don't have any other surprises waiting for me. (Like submenus repositioning) Is this an unreasonble complaint?

Thanks,

Brett

By the way...

Poster: brettzamora
Dated: Thursday October 23 2003 - 21:00:14 BST

By the way...

After all these changes... when the scrollbar does display in IE6 the horizontal scrollbar still appears at the bottom of the submenu, so the upgrade did not resolve the issue.

This problem does not occur on NS7.

Brett

Poster: John
Dated: Thursday October 23 2003 - 23:40:32 BST

scriptpath is no longer used, and hasn't been for some time. Remove it.

I really think the JS calls need to be as Andy shows in the docs, In your case that would be...



Also, in your menu code, _c=1 is no longer used. Check the menu_data.js file that is in the download and compare for the differences.

Why have you split up the code into 3 files?

Poster: brettzamora
Dated: Friday October 24 2003 - 0:02:03 BST

John... Thanks for the input. I just copied the if(ns4) test from Andy's menu.htm file, pasted in place of the version I had and the very next time I brought my page up, I got the Javascript Runtime error on line 17. The menus no longer display. I'm using IE6 Version: 6.0.2800.1106.xpsp1.020828-1920IC.

As far as the removal of the _c parameter. This is the types of change that I'm referring too. Now I get to go back through all of my menu definitions and remove that item for every menu item, plus I get to do it for every site that I want to upgrade.

The reason I break my files up like I do is for maintenance reasons. I store the style information in a seperate file so that I won't have to change it in more than one place if I ever need to change something. This would not be an issue if I only used one menu definition file. Then the style information could be stored there. Like in the samples.

By practice I have started seperating out certain types of menus into seperate files. Again, for maintenance reasons. I my particular case I have instances where different pages display a different sidebar menu, while continuing to display the same top bar menu that is on other pages.

I also have sites that have their menus generated dynamically based on who logs in. Again, it's necessary to be able to dynamically determine which menu I need to load and consequently seperate menus.

I'm not sure what the proper approach is to resolve the issue with the Javascript error. Before I put back my version of the menu, I'll try removing the _c variable from the definitions and I'll eliminate the use of the scriptpath variable. Maybe that's the issue. If not, I'll put back my version because it works.

Thanks,

Brett

Re: Downloaded V5RC17... having problems

Poster: kevin3442
Dated: Friday October 24 2003 - 0:11:37 BST

Hi again Brett,


Yup... scriptpath went away. I wasn't paying attention when that happened, so I don't know at when it disappeared... caught me off guard too. I guess it was causing too many problems for people, so they went back to a more standard way of loading the scripts.


I noticed that too... I think it's just a typo. Still, it should probably be changed to avoid confusing users who actually do take the time to look at the docs first (one always wants to encourage that behavior!)


That should work just fine for most of your visitors. But I believe the string concatenation is done so that the menu scripts can load without being eaten by personal firewall software that some people use (that alter the menu scripts thereby causing the menus to fail). If memory serves, I think that problem became apparent in the later days of v3, with Symantec personal firewall software.


The adjustment is caused by the built-in anticollision methods. It's interesting that someone else, in a recent thread (can't recall which right now), found that the collision detection wasn't working right and had the opposite complaint: they wanted the menu to adjust its position if the whole thing could fit in the space available, and resort to a scrollbar only if the menu wouldn't fit in the available vertical space. I think these polar views demonstrate a good opportunity for an option; so I agree with you Brett, that it would be a good idea to have a way to control the precedence of anticollision behaviors.


Probably not too unreasonable, although it should be taken with the understanding that this is still a beta "RC" release candidate, and one might expect some changes. Along those lines, it would probably also be reasonable to expect a couple of surprises from RC6 to RC17 I went from 6 to 11 and got a few surprises myself!

Nice to see you back on the board Brett. Cheers,

Kevin

Poster: brettzamora
Dated: Friday October 24 2003 - 0:14:43 BST

I removed the _c and the scriptpath variables across the board and left Andy's if(ns4) test in place. Now the Javascript runtime error is on line 15 instead of 17. (Accounts for the 2 lines I removed from the milonic_src.js file for scriptpath and a blank line.)

Now for some reason or other, my text box is off again. Almost as if the _subOffsetTop = -3 ; is affecting it. Whatever... it's not that big a deal. I'll figure out how to work around these minor issues I'm encountering.

Thanks,

Brett

Update on the _subOffsetTop variable...

Poster: brettzamora
Dated: Friday October 24 2003 - 0:21:38 BST

Here's what I just discovered. This offset positioning seems to be affected by whether or not your browser is maximized or not. If I have mine maximized, the -3 value works fine. If it's not maximized, I have to change it to +4. Very strange.

Seems there is an issue with how menu positioning is calculated. At least with IE6.

Regards,

Brett

More notes...

Poster: brettzamora
Dated: Friday October 24 2003 - 0:46:30 BST

Okay... after a little more testing I've found that if I set the variable _subOffsetTop to a value of 0, Netscape 7 handles the positioning of my submenu (box) perfectly, regardless of whether or not I maximize the browser window or not.

On IE setting the value of _subOffsetTop to 0 causes my submenu (boxes) to be positioned 3 pixels below the position of the default box (menu). If I change from maximized to sizeable mode with my IE6 browser the submenu (box) positions about 4 pixels above where it is supposed to appear. Keep in mind that I have the top and left values for the submenus set to the same exact positions across the board.

These characteristics can be seen at http://ecg.zware.net I'm referring to what happens in the little white box at the bottom left of the screen when you hover over the left sidebar menu options. The text in the white box changes depending on which item you hover over. This charactistic did not exist in older RC's of this menu.

The default white text box has the same top and left values as the overlay submenus. All the white textbox overlays are submenu definitions and they are dislayed with the showmenu statement. They all have the same top and left positions. There is nothing tricky being done looking for the state of the browser (maximized or not).

That's all I have for now.

Brett

Kevin... thanks for all your feedback on my previous post. It is greatly appreciated and valued.

Poster: kevin3442
Dated: Friday October 24 2003 - 1:26:26 BST

Hi Brett,


You're welcome.

I had a look at your site (nice looking site btw) and I don't get the position behavior you describe. All four of your submenu boxes appear in exactly the same position and are the same size as the default box, whether I have ie6 maximized or not. I'm using ie6/win2k. What OS are you using?

I also find the horizontal scroll bar issue to be odd at first glance. Go to the Milonic main site, and size your browser so that a scroll bar appears when you open the Samples menu (under "DHTML Menu"). Do you get a horizontal scroll bar, or just the vertical one? I only get the vertical one, although I do get both on your site. Something in your css? I haven't had time to poke around in your code... maybe tomorrow.

Cheers,

Kevin

Poster: Hergio
Dated: Friday October 24 2003 - 2:02:35 BST

Brett, I sympathize with you because of all the errors and problems you have been having with the menu upgrades. But you have to understand, the menu is still in RC and constantly being changed and updated. If you rolled out this beta version onto a bunch of sites for production, you gotta be crazy not to think there will be changes to the code before it becomes final. The menu is ever changing although it looks to be simmering down and getting close to a final release. But dont hold me to it, anythign could happen.

I agree with Kevin, that might be a good thing to have as an option. But I think its not a bad feature because it allows more of your menu to be on screen at once. But your arguement is very relevant.

I would also see if the scroll bars occur on the milonic site. Your best bey may be to wait until Milonic has a final release...then redownload all the source code files as well as menu_data file and use those as your new template for creating your menus. That way any subtle changes to even the menu_data file will be in your version (like the _c thing) and you will be less prone to errors.

Glad your sticking with the menu and helping to iron out bugs!

Thanks!

Poster: brettzamora
Dated: Friday October 24 2003 - 2:14:52 BST

Hi Dave,

Thanks for the feedback. I completely agree with you. Sometimes I forget that the menu is still in beta mode. I had to use it in a website I designed because I needed the support for long menus. It was not optional.

In any case, I appreciate the feedback that I got today. I'll definitely stick with the Milonic menu. It is an outstanding tool. I'm going to roll a new website out on Monday. It's my own companie's website. I'm experimenting today with a few new ideas and everytime I turn around, I'm amazed at how powerful a tool this menu is. Unbelievable the things you can do with it.

Thanks again for the feedback today. Keep up the good work!

Brett

Poster: Hergio
Dated: Monday October 27 2003 - 17:14:44 GMT

So Brett, what happened with the scroll bars? Do they come up on the Milonic web site?

Long menus...

Poster: brettzamora
Dated: Monday October 27 2003 - 20:11:00 GMT

Hi Dave,

I could not find the long menus sample on the Milonic website. It's almost as if that great feature has been played down. In any case, I went ahead and built a menu that would trigger the long menus flag (scrolling) and after it adjusted to use as much screen space as possible, it turned on both the horizontal and vertical scrollbars.

As I mentioned before, there was no need to have the horizontal bar and regardless of how wide I made the submenu, it still put the horizontal scrollbar. Interesting that the amount of scroll that it supported was very small. Maybe 10 pixels (?), I'd guess.

Sure wish that feature had not been changed. I'll put in a change request in the other forum to have that functionality made configurable.


Regards,

Brett

Re: Long menus...

Poster: John
Dated: Monday October 27 2003 - 20:44:42 GMT


Hey Brett -

Was just going to suggest that. Thanks, and for the reply to my questions as well. Was just curious, not pickin'.

Also, if you haven't done so already, put your 'white box' bug in the Final Outstanding Bugs area. Makes it much easier for Andy to find the problems that way.

Poster: kevin3442
Dated: Monday October 27 2003 - 20:50:12 GMT

Hi Brett,


What I meant was... the Samples menu on the Milonic site is quite high itself. If you resize your browser window's height so that it will not allow the entire Samples menu to fit, what scroll bars appear?

Kevin