Show event not working on first click, works on subsequent clicks


#1

Hi, I have this file I’ve created which has 3 buttons that display a drop-down menu, and then each menu item when clicked displays a sub-menu.

It mostly works, but I am having one issue where the first click on any menu item doesn’t seem to fire the show event for the sub-menu properly. However, if you click something else (anything else) and then click the same item again, it works. It’s just whatever menu item you first click, it doesn’t work the first time.

Why is it doing this? My RP file is attached - am I missing something?

Menus.rp (236.9 KB)


#2

The quick fix is to hide all your sub-menu dynamic panels by default.

  • When you click on a menu item, e.g., “1_Main” it has 3 actions:
    • Show the associated sub-menu, e.g., “Show 1_Sub”
    • Hide the other sub-menu, e.g., “Hide 2_Sub”
    • Hide the other sub-menu, e.g., “Hide 3_Sub”
  • Then, when a sub-menu is shown, it shows all of it’s menu elements, which are hidden by default (e.g., “1.1”, “1.2”, etc.)
  • The default visibility of each sub-menu dynamic panel is shown, so the first action to show it would have no effect. In other words, there is no change from “hidden” to “shown” so the Shown event gets called (as you can see with the Console Trace debugger) but basically ignored because the widget is already shown.
  • Clicking anywhere else, such as one of your “Menu_Hitbox” hotspots, or on the page, has an action to hide all sub-menus. Thus, after clicking “anything else” all the sub-menus get hidden, so later on showing them does have an effect because they change from hidden to shown.

A better fix would be to show all the sub-menu items by default and only hide their “parent” sub-menus by default–just like you do for the main menus, where “Level 1” , “Level 2” and “Level 3” are shown, but their parent group, “Menu1 Accordion” is hidden. Currently you don’t have any events that would hide individual sub-menu items, but even if you eventually do hide these based on an interaction (as they might if this were a true accordion menu–the whole menu structure as it is behaves as a flyout), the default for each should be shown–which is how they currently behave. Then as a general click response, you only have to worry about showing/hiding the sub-menu dynamic panel rather than coding each of those to also show/hide all their elements.

See Home Page 2 in this updated .rp file
Menus.rp (513.0 KB)

A better fix even yet would be to assign a Selection Group to each menu item, so only one item may be selected at a time. A Click or Tap can toggle the selection state, and a Selected or Unselected event can toggle the visibility of its own sub-menu. Thus, clicking on “Alpha” would change its selection state; the first time from unselected to selected and this would trigger its “Menu1” group to show. Clicking on “Beta” would select it–and because it is a member of the same Selection Group (I named “Top Menu Item”) all other members–including “Alpha”–get unselected, thus Alpha’s “Menu1” group gets automatically hidden. So, you don’t have to worry about coding a bunch of Show/Hide actions, and more importantly the “Alpha” widget doesn’t need to know anything about the other menu items or how many there are. So, if you need to add more menu items (e.g., “Delta”, “Epsilon”) you can duplicate a whole Menu group (or delete menu groups) without having to change your code on each menu item. Likewise, each item in the next menu level (i.e., your “1_main”, “2_main”, and “3_main” widgets) can have a Selection Group (I named this “Main Menu Item”) and toggle the visibility of its own sub-menu (i.e., “1_sub” etc.)
See Home Page 3 for this approach.

I made some further simplifications:

  • The topmost menu items (Alpha, Beta, Gamma) are reduced to one widget. If you are not going to use multiple widgets per element (e.g., maybe an icon, text label, separate background etc. per menu item) it is easier (to create as well as see and maintain code) to use as few widgets and “nesting” (panels and groups within others) as possible.
    • This can also help avoid mistakes like you inadvertently made with your “_Hitbox” hotspots, where each hotspot is sized differently relative to the text under it: Alpha’s hotspot is larger than “Alpha”; Beta’s hotspot is larger to the right; Gamma’s hotspot is too small–so clicking on the last letter does nothing.
    • I added some padding to the style of these widgets just to demonstrate how their “hit area” can easily be made larger than just the text, and in a consistent manner–e.g., 10 px on all sides of the text.
  • Likewise, I removed some unnecessary nesting in the menu groups and sub-menu dynamic panels…and I could have gone even further with this.
  • Notice the Page Click or Tap event is much simpler. It only needs to set each top menu item to unselected (Set Selected/Checked to “false”) in order to cause them to hide their own “child” elements, which in turn causes each child to hide their children. This is an object-oriented approach–which you basically took when you had each sub-menu dynamic panel hide all its child widgets…only they didn’t need to.

#3

Wow, thank you for taking the time to explain this all. I haven’t been exposed to selection groups previously, but that seems like the way to go here. Thank you again.