Project

General

Profile

Bug #1739

Nesting of more than one WPopupMenu widgets

Added by Стойчо Стефанов Stoycho Stefanov over 7 years ago. Updated over 7 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
#1

Updated by Стойчо Стефанов Stoycho Stefanov over 7 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

#2

Updated by Koen Deforche over 7 years ago

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

Updated by Стойчо Стефанов Stoycho Stefanov over 7 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

#4

Updated by Koen Deforche over 7 years ago

  • Status changed from InProgress to Resolved

Hey,

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

Regards,

koen

#5

Updated by Стойчо Стефанов Stoycho Stefanov over 7 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

#6

Updated by Koen Deforche over 7 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

#7

Updated by Стойчо Стефанов Stoycho Stefanov over 7 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

#8

Updated by Koen Deforche over 7 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

#9

Updated by Стойчо Стефанов Stoycho Stefanov over 7 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

#10

Updated by Стойчо Стефанов Stoycho Stefanov over 7 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

#11

Updated by Koen Deforche over 7 years ago

Hey,

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

Regards,

koen

#12

Updated by Стойчо Стефанов Stoycho Stefanov over 7 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

#13

Updated by Стойчо Стефанов Stoycho Stefanov over 7 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

#14

Updated by Koen Deforche over 7 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

#15

Updated by Стойчо Стефанов Stoycho Stefanov over 7 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

#16

Updated by Стойчо Стефанов Stoycho Stefanov over 7 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

#17

Updated by Стойчо Стефанов Stoycho Stefanov over 7 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

#18

Updated by Koen Deforche over 7 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

#19

Updated by Стойчо Стефанов Stoycho Stefanov over 7 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

#20

Updated by Koen Deforche over 7 years ago

  • Status changed from Resolved to Closed
#21

Updated by Стойчо Стефанов Stoycho Stefanov over 7 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

#22

Updated by Koen Deforche over 7 years ago

  • Status changed from Closed to InProgress
#23

Updated by Koen Deforche over 7 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

#24

Updated by Koen Deforche over 7 years ago

  • Status changed from Resolved to Closed
#25

Updated by Стойчо Стефанов Stoycho Stefanov over 7 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

Also available in: Atom PDF