Wt

Hey,

I cannot remember how it was in previous versions, but it seems to me to be a bug, that when an checkable WMenuItem of a WPopupMenu is selected its state doesn't change. On the contrary, a click on the item's check box will take effect and a state change can be recognised later in a callback connected to aboutToHide signal. Is it a feature that the state doesn't change when the click is on the item's text and not on its checkbox.

Regards,

Stoycho

Hi,

on my fist click on a item of a popup sub-menu a get this error:

Wt internal error: TypeError: Wt3_3_0.getElement("cohd5c8l") is null, code: undefined, description: undefined

and when I close this error message and click somewhere else I get:

Wt internal error: TypeError: j324 is null, code: undefined, description: undefined

Unfortunately, I cannot yet narrow down my project so that I can reproduce it in order to provide a test example.

regards,

Stoycho

Hey,

nested popup menus are now ok, but I still have the other two problems with the checkable menu item http://redmine.webtoolkit.eu/issues/1739#note-1 and the wt internal errors http://redmine.webtoolkit.eu/issues/1739#note-3.

regards,

Stoycho

Hey,

I've addressed the checkbox item; I could not reproduce the error though ? Could you verify how I can reproduce that ?

Regards,

koen

Hey,

Ooops I wasn't clear with my last message. I could reproduce the check box problem, and I've fixed this now (latest git). But i could not reproduce the JavaScript error ?

We are certainly determined to resolve these issues (changed behaviour) w.r.t. 3.2.3.

Regards,

koen

Hey,

that sounds good! I'll let you know if I can provide a test example for the JS error. For now it seems to be an error in my application, but I still cannot find the reason of it.

have a nice day,

Stoycho

Hey,

Thanks alot for the test-case. There was indeed an optimization path wrongly being taken here...

Regards,

koen

Hey,

there is another one bug in this context (with this "panel" and "widget" from last test-case). There is something wrong with the mouse event signals of overlapping widgets. I'm now trying to narrow down a test-case for it. I hope I can send it to you today. Could you hold the release for a while just to fix it as well.

Regards,

Stoycho

Hey,

could you try the following:

in the last test-example click somewhere on the Panel with the right mouse button to show the popup menu. Than press F5 to refresh the page. The popup disappears and you cannot escape from this state, i.e., you cannot show the popup again (and probably other signals and actions are blocked).

regards,

Stoycho

Hey,

I get a different behaviour, still not entirely okay, but not as messed up : when I refresh the popup indeed disappears, and the next click is ignored (since it is probably used to 'hide the popup'), but after that the UI still works. This might be a consequence of changes I did recently.

Can you check the latest git ?

Regards,

koen

Hey,

I'll build now the git and let you know if something had changed.

I still cannot reproduce the problem about I wrote in http://redmine.emweb.be/issues/1739#note-12. Thus, you can just ignore it for now, but it is quite strange: a doubleClicked signal is emitted even on single click. Very strange, but it seems to be not so trivial to narrow down a simple test-case.

Regards,

Stoycho

Hi Koen,

I build the git and it seems that the bugs are fixed (http://redmine.emweb.be/issues/1739#note-10 and http://redmine.emweb.be/issues/1739#note-14)

Regards,

Stoycho

Hey,

Got it. The bug was triggered by the fact that you had doubleClicked() event handlers attached to nested widgets ... I've resolved it in my copy and will push it later.

Regards,

koen

Hey,

it is nice to read this message. Thanks a lot! Taht was all from me for now. It seems everything else in my project to be good w.r.t wt-3.3.0. You have green light for the release :-)

regards,

stoycho

Hey Koen,

I just tested the checkable WMenuItem. Its behaviour is now better but still wrong for me. When I click the item the check box is changed (correctly), but the check state still unchanged, precisely spoken if you test against isChecked() the old state is returned (I suppose). You can test it with the same patch as in:

http://redmine.webtoolkit.eu/issues/1739#note-7

the text message does not match the check box "visible state".

Clicking the check box is always correct.

Regards,

Stoycho