Project

General

Profile

Actions

Bug #1739

closed

Nesting of more than one WPopupMenu widgets

Added by Стойчо Стефанов Stoycho Stefanov over 11 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
03/04/2013
Due date:
% Done:

0%

Estimated time:

Description

Hi,

in Wt-3.3.0-rc3 when nesting more than one WPopupMenu sub, menus "deeper than first level" are not hidden on hiding parent menu. It worked for me with wt-3.2.3. Here is a patch for the TreeViewDragDrop example that demonstrates this behaviour.

Regards,

Stoycho


Files

TreeViewDragDrop.patch (658 Bytes) TreeViewDragDrop.patch for /examples/TreeViewDragDrob.C Стойчо Стефанов Stoycho Stefanov, 03/04/2013 01:24 PM
TreeViewDragDrop.patch (941 Bytes) TreeViewDragDrop.patch patch about checkable WPopupMenuItem Стойчо Стефанов Stoycho Stefanov, 03/14/2013 08:01 AM
createPainedWidget.cpp (3.76 KB) createPainedWidget.cpp example of the JavaScript problem Стойчо Стефанов Stoycho Stefanov, 03/14/2013 01:43 PM
Panel.zip (11.3 KB) Panel.zip test-case overlapping widget and doubleClicked Стойчо Стефанов Stoycho Stefanov, 03/15/2013 03:09 PM
Checkable_MenuItem_click.png (16.8 KB) Checkable_MenuItem_click.png WMenuItem click Стойчо Стефанов Stoycho Stefanov, 04/10/2013 02:11 PM
Actions #1

Updated by Стойчо Стефанов Stoycho Stefanov over 11 years ago

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

Actions #2

Updated by Koen Deforche over 11 years ago

  • Status changed from New to InProgress
  • Assignee set to Koen Deforche
Actions #3

Updated by Стойчо Стефанов Stoycho Stefanov over 11 years ago

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

Actions #4

Updated by Koen Deforche over 11 years ago

  • Status changed from InProgress to Resolved

Hey,

Got it. I've fixed this in latest git.

Regards,

koen

Actions #5

Updated by Стойчо Стефанов Stoycho Stefanov over 11 years ago

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

Actions #6

Updated by Koen Deforche over 11 years ago

Hey,

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

Regards,

koen

Actions #7

Updated by Стойчо Стефанов Stoycho Stefanov over 11 years ago

Hey,

here is a patch that demonstrates the error. I tested it with Wt-3.2.3 and Wt-3.3.0 and the behaviour is different. When I click on checkable WPopupMenuItem (click on its text part, not the check box) I expect that the item is selected and the check state is toggled as it is in Wt-3.2.3. In Wt-3.3.0 you have to explicitly click on the item's check box in order to change the check state, otherwise the item is just selected but the check state remains unchanged.

What is the right behaviour and should I implement the old one by myself (as it was in Wt-3.2.3) or it is an error in Wt-3.3.0.

regards,

Stoycho

Actions #8

Updated by Koen Deforche over 11 years ago

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

Actions #9

Updated by Стойчо Стефанов Stoycho Stefanov over 11 years ago

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

Actions #10

Updated by Стойчо Стефанов Stoycho Stefanov over 11 years ago

Hey,

I got it! It is neither related to the popup menu nor to the menu item.

I'm using a popup menu just to select a composite widget which is to be created. This composite widget contains a painted widget and the popup action adds it to the "parent" widget of the popup menu. When the widget is added to the "Panel" (as in the provided example) the JavaScript cannot find the painted widget. After browser refresh the painted widget is there and you can use the popup menu normally.

In Wt-3.2.3 is fine, i.e., the error come with 3.3.0

Regards,

stoycho

Actions #11

Updated by Koen Deforche over 11 years ago

Hey,

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

Regards,

koen

Actions #12

Updated by Стойчо Стефанов Stoycho Stefanov over 11 years ago

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

Actions #13

Updated by Стойчо Стефанов Stoycho Stefanov over 11 years ago

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

Actions #14

Updated by Koen Deforche over 11 years ago

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

Actions #15

Updated by Стойчо Стефанов Stoycho Stefanov over 11 years ago

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

Actions #16

Updated by Стойчо Стефанов Stoycho Stefanov over 11 years ago

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

Actions #17

Updated by Стойчо Стефанов Stoycho Stefanov over 11 years ago

Hey,

back to the overlapping widgets and the doubleClicked signal. I narrowed down a test example.

1. create a widget: right mouse click -> in page's popup and click on "widget"

  1. try to select the widget: left mouse click on the widget (the ellipse) (curiously the right mouse click is ok)

I really haven't got a clue what is wrong, but the property dialogue just do not have to be created.

I'm not sure that it works even with wt-3.2.3, but it is a part of an old design that I developed for wt-3.2.1 (as far as a can remember).

best regards,

Stoycho

Actions #18

Updated by Koen Deforche over 11 years ago

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

Actions #19

Updated by Стойчо Стефанов Stoycho Stefanov over 11 years ago

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

Actions #20

Updated by Koen Deforche over 11 years ago

  • Status changed from Resolved to Closed
Actions #21

Updated by Стойчо Стефанов Stoycho Stefanov over 11 years ago

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

Actions #22

Updated by Koen Deforche over 11 years ago

  • Status changed from Closed to InProgress
Actions #23

Updated by Koen Deforche over 11 years ago

  • Status changed from InProgress to Resolved

Hey,

I believe it's actually a general problem with WLabel::clicked() propagating the value of its buddy checkbox before changing it --- but I've fixed a workaround in WMenuItem for the time being.

Regards,

koen

Actions #24

Updated by Koen Deforche over 11 years ago

  • Status changed from Resolved to Closed
Actions #25

Updated by Стойчо Стефанов Stoycho Stefanov over 11 years ago

Hey,

I found another bug. A click on the clickable menu item itself (not the checkbox or the label, see snapshot) is not recognized, i.e., popup_->result() is null.

Regards,

Stoycho

Actions

Also available in: Atom PDF