I want to use the horizontal menu to change a session custom property and display as selected when clicked. I can bind to each of the items’ styles for the display (little bit inconvenient but it will work), however I’m not sure how to do the writing to the session property?
Also, when I tap on the buttons on mobile, it keeps selecting the button text and then chrome brings up the “search the internet for the selected text” prompt at the bottom… can I disable selecting text?
Ugh, I am this close to what I'm looking for, I just can't get the pop-up submenus to close after the user clicks on them. I've tried all sorts of things in the onItemClicked event script - including setting props.items=[], refreshing the binding to props.items, setting position.display=False, meta.visible=False, navigating to a new view (this doesn't work because my horizontal menu is on a north dock), even system.perspective.closeDock (a bizarre fail because the dock disappeared but left the horizontal menu on the screen, overlaying the primary view until I clicked outside the menu).
The only thing that closes the pop-up menus is a full refresh, which is way too disruptive.
To summarize: the goal is to use the horizontal menu not for navigation, but to set a session custom property value (which in my case is used to 'navigate' a functional location hierarchy that influences application behavior and filtering of datasets across many pages). The horizontal menu has a lot of valuable built-in functionality that would be hard to recreate from scratch (scroll arrows, dynamic pop-up submenus that auto-size and auto-position correctly, etc.) We can exploit the item.target value in the onItemClicked event to update the session custom property, but the horizontal menu component assumes the click will be followed by a navigation event that rebuilds the menu, so no cleanup is done post-click.
If you're trying to use a Navigation component for something other than Navigation, then your best course of action is to build your own component. The Horizontal Menu could be impersonated by a Flex Container with internal Labels which each open a relatively positioned modal. The referenced Modal would need to accept parameters, and would itself be a Flex Container which has Labels.
This would leave only the scroll arrows for you to handle, though these could also be impersonated by Icons as the first/last components in the Flex Container.
I tend to agree with @cmallonee here:
If it requires to jump through hoops to hack a component into doing something else than what it was intended to do... Just rebuild one yourself that's adapted to your needs. It might seem like more work at first, but how much time have you invested into this already ? And yet you're stuck on something that wouldn't be an issue with your own component.
When i click on a menu item it closes everything? What version are you using?
Got a copy of the view? and a video of what is going wrong
Edit ah read the other topic, you are trying to use the target as a variable for your page... that wont work, You are gonna be better of to use the title and / or path as a key to a list of variables/params
Yeah I stood at that fork in the road several hours ago and wound up thinking, "why build all of this stuff from scratch when the horizontal menu seems to have it all built-in from the start?" I didn't realize that the browser navigation behavior was as rigid as it is.
Actually, I am using it for navigation - just not directly at the page/URL/view level. It's very much a navigation of a data hierarchy, and the standard component functionality lines up very well with what is being navigated. Mostly.
Ah, that's the tricky part. How will the component be able to tell how many items fit in the container width and thus when & where to insert the icons? And how will this behave responsively so the items are rebuilt and arrows shifted as the window size changes (e.g. rotating a tablet from portrait to landscape)? Even the native horizontal menu struggles to handle this. This is the point during blueprinting where I decided the horizontal menu would probably save me a ton of time.
I'll post a suggestion on the ideas page. Seems like it wouldn't be too hard to add a couple of properties to each props.item object in the menu. One being a switch that supresses the default browser navigation action, and the second being a data object that could hold whatever custom data the user wants to access on the onItemClicked event. Would probably make sense to add this to the vertical menu component also.
Use a container instead, set the overflow of its parent container to visible and let your sub-menu overflow.
It can be a bit tricky to get right, depending on how complex the whole thing needs to be, but I've used this a few times. It helps if you're comfortable with css.