[OutSystems UI] Menu not highlighting active item
Forge component by OutSystems R&D
Application Type

We upgraded OutSystems UI to the latest version (2.6.13), and since then the menu does not highlight the active item by default out of the box - the active item index needs to be manually set on the menu block for each screen.

Hello Kristi.
Can you please provide more context? What was your previous version, what changed on the app, and we're talking about Reactive Web or Mobile? Doing that automatically isn't something that is done by default.
Could you share a module with that so that we can try to help?
Thanks for reaching out.


Hello Goncalo,

I can't say for sure what our previous version was, but I believe it might have been 2.6.11, or earlier. Nothing was changed on our existing apps, just after the upgrade we discovered that menu items weren't highlighting correctly, and upon creating a new app, they also don't highlight correctly. These apps are reactive.

"Doing that automatically isn't something that is done by default." - do you mean the intention now is that you do have to set it manually? When I say setting it manually, I mean that now we have to go into every screen and set to ActiveItem index on the menu block. In previous version of OutSystems UI, we did not have to do that.

Hello @Kristi Kitz,

You should use the integer according the page that you want to mark as active.

For example this link:


I have the integer "1" selected like this:

Hope it helps,

Nuno R

Hi Kristi. I believe I misunderstood the issue at first. To have more information can you tell me the platform server version your environment has and if there was any recent upgrade? If so, which was the previous version. As far as I know, in OutSystems UI we never had any logic to do that but I believe our client runtime did  something like that so I need this information to follow this up internally.

Thank you in advance.



Hi, in the new Reactive Web, you should set the active menu/submenu by menu position index (start from 0).

However this will cause problem with dynamic menus (appear/disappear based on role) because the menu position index is not valid anymore.

I hope Outsystems can reconsider the menu approach... 

@Gonçalo Martins @Nuno Ricardo Rodrigues 

Hello @Harlin Setiadarma ,

I agree with you that the current approach is not perfect.

I think if an application use dynamic menus, maybe is better to build a custom menu and dont use the one OS give an example.

Hope it helps,

Nuno R


I agree with @Harlin Setiadarma; dealing with active menus/submenus has not been a smooth experience in Reactive at all. OutSystems generally tries to follow the 80/20 rule, but I feel like in this case the implemented use case was the 20. :( It is extremely typical in applications to hide or show menus based on roles, which means that the pages using the menu have no idea how many menu items will be showing, or what index each one will be at. The way Traditional Web did this was much better.


Hi JJ.
I already reported this internally to the right team, so I hope to have some feedback asap.
Meanwhile, to provide more information to that team I would really appreciate if @Kristi Kitz could provide some of the additional information I asked for.
Thank you.


Hi @Justin James,

As I told to @Harlin Setiadarma I agree with your point of view.

I had to implemented menu with rules, and I have build one from scracth.

Maybe OS will review this issue.

Best Regards,

Nuno R

First off, I agree that this is poor design, having to indicate what is the active item by using an index.  Even if there is not much role based stuff, simply adding a new screen somewhere low in the index, means you have to go through all screens that come behind it to change the ActiveItem parameter passed to the menu.

So I played around with this a little in my personal environment, and also had some trouble with previous menu item staying selected, and looking into the code, i didn't see a place where items were getting deselected explicitly.

So I decided to find a way to solve following :

  • hiding or showing menu items should not break the active item
  •  previous selection does not linger

all the while, trying not to deviate too far from just using the menu as it is made available by OS UI module.

See attached oml, this is what I've done :

  • when a menu item is not relevant for a user, instead of putting it inside an if, use conditional inline style display:none, this does not break the indexing (of course, don't use this if you want to hide the existence of the screen to curious users and of course your screen itself should enforce the limited access)

  • write my own javascript bit in the menu OnRender to also remove the active class of all not-selected items

(notice the DEPRECATED, OS is working on this I guess, but when I make new screen in new application, it still starts with this deprecated stuff)

All of the above only works for menu's with 2 levels, not more.



Hello @Dorine Boudry .
The deprecated just means you're not using the latest app templates or OutSystems UI versions since there are some new methods we've created based on feedback from our community. The new method has more functionality but when used like one that is Deprecated will work exactly the same way.


ok, thanx,

ill look into updating my templates


so i have done some thinking about how to avoid having to pass in the ActiveItem from each screen, and made some adjustments to my menu onRender.

If ActiveItem is not set for a given screen, I try to match the screen to one of the url's in the menu, and set that as active menu/submenu item.

See attached modified oml


Hello all.

I have an update from my peers on the team responsible for the client runtime.
After I reported this to them, they found out that this feature was broken during the transition to react 16 and they will fix this sooner.
It is supposed to automatically add the "active" class to a link when the link is to a screen and it matches the current screen we are at, including the parameters.
Thank you for your feedback and keep an eye on the release notes on future releases.



This is still difficult behavior to work with. For example, if I have an icon within the link, it's hard to control it like this. If I want to style something other than the link (like if I wrap the links in Containers), I can't do anything with those elements. Etc. etc. etc.

While this kind of "automagical" behavior makes it easy for the complete newcomer, for an experienced professional, or for someone working with a designer who has ideas other than extremely basic things, this behavior makes everything much worse.

Until CSS gets a "parent" selector, this behavior is really not what we need or want. The older way of doing things, while less automagical, was the right way to do things for anyone needing any kind of semi-sophisticated behavior.


Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.