Wt

Hey,

Indeed, and this is unfortunate as it slipped into 3.3.1.

The reason is a preventPropagation() that was added in WMenuItem::clicked() which also prevents this signal to be a trigger to close menus.

I will look into a possible workaround and/or patch to 3.3.1

Regards,

koen

Hey,

I've got a fix ready for git. Instead of preventing propagation on a menu item, we now do it (correctly) for popup widgets since these do not actually have a predictable DOM parent and whose event propagation can cause unexpected consequences.

A workaround is a bit more involved, I'm afraid. You need to call the following function on each item in a plain WMenu (i.e. not a WPopupMenu).

void fixItem(WMenuItem *item) {
  Wt::WAnchor *anchor = (Wt::WAnchor*)item->widget(0);
  if (anchor)
    anchor->clicked().preventPropagation(false);
}

I may have spoken too soon.

I am seeing a very odd behavior where the contents stack displays the wrong widget. If I don't call setInternalPathEnabled() on the submenus it works correctly, but of course then I don't get navigation on sub-menu items (specifically, my anchors to menu items don't work).

I can't re-create this yet, but I can give you something that seems to behave in a similarly wrong way (do these steps in order):

1. Build and run this, then connect with your browser

1. Choose Colors~~Bright~~>Red
   
2. Then choose Colors->Black

Notice that the popup menu doesn't disappear when you choose "Black". I see this same behavior, but it also chooses the wrong widget from the widget stack. Maybe this little test will help, if not I will try to re-create the exact problem next week.

- Bud

Hey,

Indeed something still wasn't quite right. I've fixed this now in git.

I could also reproduce the situation where the wrong item was displayed (the event simply wasn't processed properly).

Find attached a modified version of your test case: you need to specify the internal path at which you want to deploy a menu (the default is to take the current internal path which is most likely wrong).

Regards,

koen

There is another bug in the attached file. I added a menu item before the popup, and it stays selected even when the popup is selected.

About paths, I have solved my problem by giving widgets a fully qualified internal path for identification, then building the path component on the fly by removing the menu's internal base path from the widget's fully qualified path. It's not ideal, but I cannot see a better approach.

This may sound convoluted, but when it comes to locating widgets it's important to not let these names propagate all over the place. In particular, if I have a widget that builds WAnchors to other widgets in my application, I should be able to declare a link to the other widget without having to have an instance of the widget - the way links are supposed work, after all.

In other words, I create a WAnchor that links to "/devices/leases/42", and the "leases" widget recognizes itself in the path change, then brings up lease 42. This name - "/devices/leases" - is kept in a central place so that any widget can build an anchor to any other widget without having to have an instance of the target widget.

I read somewhere online from you or Wim that the approach to internal paths was to not have a central url router, but to instead let each widget process its own path handling. I like that model, but I think it requires that you have well known names for widgets located somewhere centrally in your application. If you agree with that statement, then IMO it becomes clear that dealing with partial paths is not a great idea, especially when two widgets may have the same partial name, but be very different things.