Wt

Yes, that's the intention. The application would need to retain state, of course, the test app doesn't for simplicity. The user would see some checked and some unchecked items as the menu opens, allowing him to select or deselect items.

This works fine with wt 3.3.0 BTW, I went back to that version for now.

Regards

Jan

Sorry, I might be wrong about 3.3.0. Please let me check that again.

If I understand you correctly, the isChecked() return value isn't meant to be evaluated inside the triggered() signal, right? I would need to keep state and toggle the cached state myself?

Hey Jan,

Running your test-case I see the correct behaviour (printing "checked" for the item that I check) as far as I understand, that's with Wt 3.3.3 (RC1).

127.0.0.1 - - [2014-May-19 15:23:54.773680] "GET /resources/right-arrow.gif HTTP/1.1" 200 57
slot bound menu item triggered with value 2 (checked)
menu triggered, unbound item not selected
127.0.0.1 - - [2014-May-19 15:23:56.985457] "POST /?wtd=zCtJgAoHGGpdtqbS HTTP/1.1" 200 166

If you do not reuse the same popup then indeed you will need to read and copy the state from one popup menu to another. But why wouldn't you reuse the same popup menu over and over?

Regards,

koen

Hi Koen,

out-of-office-error, sorry for the delay.

Koen Deforche wrote:

Running your test-case I see the correct behaviour (printing "checked" for the item that I check) as far as I understand, that's with Wt 3.3.3 (RC1).

Same here with current git (54837d1cb3223fac68ac555c2009ea70cc61c15c). Thank you very much.

I have not re-tested with 3.2.0. Might come down to have changed the boost version as well. Please let me know if you want me to check again.

If you do not reuse the same popup then indeed you will need to read and copy the state from one popup menu to another. But why wouldn't you reuse the same popup menu over and over?

Because the menu's contents is highly volatile, and it's a more straightforward design to simply delete it and create a new instance from the backend's current data. The keep-state-or-not-discussion wasn't about the necessity to do that. It was more myself meditating possible ways to implement it at all with what you called expected behaviour, i.e. isChecked() not returning true with a ticked check box. By toggling a cached state, that is.

Jan Lindemann wrote:

This is mostly the example from Bug 3029, with added checkboxes and Koen's workaround not to delete the popup menu in the context of the WPopupMenu::triggered() signal.

FWIW, this is also fixed in current git.

Best regards

Jan