Scroll Bars being automatically created, even if not needed

[Clueless_in_Cincinnati]

Hello to All - I am being thrown (literally) into the Web arena. I have searched through several sections of the forum (nicely done, by the way), but have not seen an issue similar to ours, so I am going to post the question.

We are using the Milonic menu to create two menus in a frame, using DIV tags of equal height to set the two in relative positions. Ultimately, we will be creating the data dynamically for these menus, although we have been able to reproduce the issue with hard-coded information. We are attempting to use the menus with automatic scrolling. I will enclose the example site we have:

http://www.cpulink.biz/MilonicTesting/Layout1.htm

My issue is that the second menu seems to be carrying the height of the first <DIV> tag along, and is automatically creating the scroll bar, even though there are only two options in the second menu.

Again, brand new to the Web-world in general, so don't beat me up too much if I have made a stupid mistake. Thanks!

[Bob Martin]

... since I cannot reproduce the same scrolling issue when substituting non-Milonic menu script with plain HTML.

Can anyone from Milonic confirm that this is a bug?

[Bob Martin]

Since this issue intrigues me, I took the source and modified it so that the two menus being built were horizontal from each other... and the result was then the appearance of the horizontal scrollbars!

Hmmm... so then I tried placing 3 menus having the same height/width on the same page (two horizontally positioned from each other, and the third menu below these two menus), each with their own <div> tags for positioning purposes. The result - the first menu was fine, the second menu had horizontal scrollbars, and the third menu had BOTH vertical and horizontal scrollbars!

So my take on this is that the routine used to determine both the height and width of the menu and, therefore, the need for the appropriate scrollbars within each <div> tag, is not being initialized for each menu, i.e. some cumulative number is being used for this purpose.

Here's the HTML code that I used (the .js file just defines and draws the menu):

Code: Select all

<div id="K1" style="position: absolute; top:0px; left: 0px; width: 210px; height: 250px; z-index: 9; border: none; background-color: #66CCFF; overflow: auto;">
   <SCRIPT language=JavaScript src="Layout1_Keys.js" type=text/javascript></SCRIPT>
</div>

<div id="K2" style="position: absolute; top:0px; left: 250px; width: 210px; height: 250px; z-index: 9; border: none; background-color: #66CCFF; overflow: auto;">
  <SCRIPT language=JavaScript src="Layout1_Keys.js" type=text/javascript></SCRIPT>
</div> 

<div id="K3" style="position: absolute; top:300px; left: 125px; width: 210px; height: 250px; z-index: 9; border: none; background-color: #66CCFF; overflow: auto;">
  <SCRIPT language=JavaScript src="Layout1_Keys.js" type=text/javascript></SCRIPT>
</div>

I'm stumped as to a workaround - any suggestions?

[Bob Martin]

The _CFix=1; variable assignment, posted as a fix for Contribute users, fixed this issue as well (no more scrollbars when not expected).

Now I feel better

[kevin3442]

Just curious... why place the menu code inside of DIVs? You don't have to do that if your main purpose is for positioning, even if you have multiple "main" menus on a single page. I only bring this up because I've seen other instances where loading the menu scripts into a DIV has caused odd results.

Kevin

[Bob Martin]

Kevin,

The reason to use <DIV> tags in this case is to provide a 3D-like background over which the menus would be displayed, and which is to the left of another "layered" area over which the main application screens are displayed:

Code: Select all

<div id="KeyOptContent" style="position:absolute; left:8px; top:21px; width:210px; height:512px; z-index:2; border: none; background-color: #66CCFF; overflow: hidden;">

  <div id="Opts" style="position: relative; top:0px; left: 0px; width: 210px; height: 250px; z-index: 3; border: none; background-color: #66CCFF; overflow: auto;">
   <SCRIPT src="Layout1_Options.js"></SCRIPT>
  </div>

  <div id="Keys" style="position: relative; top:0px; left: 0px; width: 210px; height: 250px; z-index: 3; border: none; background-color: #66CCFF; overflow: auto;">
   <SCRIPT src="Layout1_Keys.js"></SCRIPT>
  </div>
</div>

<div id="KeyOptBack" style="position:absolute; left:12px; top:25px; width:210px; height:512px; z-index:1; background-color: #b5b5b4; border: none; margin:4px;"></div>

<div id="AppContent" style="position:absolute; left:250px; top:21px; width:730px; height:512px; z-index:2;border: none; background: #66CCFF;">
...
</div>
 

So the result is what is displayed on the prior-displayed link. Also, this approach supports the IE-imbedded scrolling if, in this case, line options or command keys extend beyond its specific fixed region. Net - if either line options or command keys extend beyond its predefined region, scrollbars appear.

[Bob Martin]

Now, while having used the Contribute (_CFix=1) fix for quite some time to get around this really old issue, I am now running into a problem using tool tip text

When I hover my mouse over a menu item with tool tip text, within a menu which is inside a scrollable <div>, and that vertical scroll bar is not in its top position (for example, I've scrolled down to view a menu item near the bottom of the list which was not initially viewable), the scroll bars automatically reposition so that the first menu item is shown right when the tip text is about to display (the menu "jumps" back to its initial state).

FWIW - this is not the behavior when I do not use the Contribute fix... but then I always get the scroll bars