I have navigation toolbar button on most web pages, it is build dynamically and looks good. However, there is a little issue with it. There is a vertical scrollbar that needs to be used to scroll to see last menu item.
Is it possible to control the default height of the WebPopupMenu and eliminate the need to scroll?
If I remember correctly I added a feature request for that.
I haven’t follow up on that and I don’t have the case number at hand.
Do you happen to know the reference of this request?
I would like to record it in our Jira ticket.
Great, thank you
what is the problem you wish to solve by limiting the height of the WebPopupMenu ? I may guess the answer, but prefer not.
Thanks
The problem is that the menu is not tall enough - hence the user needs to use vertical scroll bar to get to the menu item that is not visible. It is not about limiting the height, it is about controlling the height of the menu via code to eliminate the need for the vertical scrollbar. I hope this helps to clarify.
Looking at your screenshot, the user would have to scroll the entire page. Have you thought about putting the groups that are between the separators to not submenus instead?
1 Like
As @Greg_O answered, the user woud have to scroll the page then. The more you add submenus, the higher is the WebPopupMenu, and the WebPage grows higher.
One way to solve your problem using a WebPopupMenu would be to “segment” what you display in it:
- The user clicks on a Menu, the PopupMenu displays only Level 1 submenus
- He clicks on a Level 1 submenu, for example Reporting, you clear the list and then list the choices (submenus) for the Level 1
- He clicks on one of the choices, you dismiss the Popmenu and bring the appropriate page
- For the user to go back when he realizes he selected the wrong Level 1 submenu, you provide a Back button that clear the list and lists again the Level 1 submenus
This works as long as a list is not big enough to bring it higer than the space betweenn the Menu and the bottom of the screen. Thing is you do not have any control on that since the user may have a small monitor, for example a HD monitor instead of a Full HD monitor or larger. The same issue arises if the user resizes the browser,
It is about two menu items on the menu, not the web page showing list behind. Btw, the menu has separators.
The menu you see on the snapshot belongs to Navigation tooolbar button, this has nothing to do with the size of the page, the page itself is much taller.
Our users don’t like extra clicks. Currently each menu item shows new web page, there are no submenus needed. The web page itself is normally maximized (95 or 99% of the time), monitors used are typically 27" or more. .
I understand that, but how can they tell the applications what they wish to do, the application don’t read their mind ? One other way would be that when the user hovers over a Level 1 choice, you bring another PopupMenu to the right with the choices for the Level 1 hovered. If afterwards the user goes to another Level 1 choice, then the second PopupMenu is cleared and updated with the new choicees. This is the way it works with OS menus: you clcik first a menu a move the mouse to the desired choice and then click.
It is not the size of the monitor that counts, but it’s resolution. If for example you have a 32-inch monitor, but it’s resolution is set at 642x480, not much will be displayed.
1 Like
Gilles, it doesn’t matter what I think about this, I have jira ticket about the vertical scrollbar on the menu and Alberto has already created enhancement request some time ago prior to me asking this question. Personally I don’t mind scrolling. As to the resolution of the monitor, I understand you are giving just an example but our users are using this web app for work and they want to see as much data as possible, they have high resolution for that matter. As to the clicking, of course nobody counts clicking but this is the proverbial complain.
Thanks for all your suggestions. However, I am just humble developer who converted well established web app from Xojo2018 to Xojo2024. The top priority is to preserve the original functionality.
Can this be changed in CSS? Just throwing out wild ideas.