Bug #1512: WDialog: cover not correctly set - Wt - Redmine

Actions

Copy link

Bug #1512

closed

WDialog: cover not correctly set

Added by Rob Van Dyck about 12 years ago. Updated over 11 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Koen Deforche

Target version:

3.3.1

Start date:

11/06/2012

Due date:

% Done:

Estimated time:

Description

Hi,

When I have multiple dialogs open, the order of closing disturbs the process of deciding whether the cover should be shown. See the attached testcase to reproduce the problem.

This could be fixed by remembering the requested covers in WApplication and deciding there if the cover should be shown, instead of deciding this within WDialog.

In my code I had a confirmation popup that created and showed another popup (with some logging info) on confirmation (which closes the confirmation popup). As a workaround I used WServer::post to create the second (logging) dialog, so the first one is allready gone when the second one is created.

I'm using Wt 3.2.1, but the WDialog::setHidden code in 3.2.3 seems to be identical.

Kind regards,

Rob.

Files

main.cpp (1.86 KB) main.cpp

Rob Van Dyck, 11/06/2012 03:29 PM

Actions

Copy link

Updated by Koen Deforche about 12 years ago

Status changed from New to InProgress
Assignee set to Koen Deforche

Actions

Copy link

Updated by Koen Deforche almost 12 years ago

Status changed from InProgress to Feedback

Hey Rob,

I'm a bit reluctant to fix this. Surely dialogs stack on top of each other and thus it makes sense to also show and hide them in the order of a stack ? How do you end up not doing this in your application ?

Regards,

koen

Actions

Copy link

Updated by Rob Van Dyck almost 12 years ago

Hi Koen,

Best wishes for 2013 ;-).

Maybe it is enough if you can give a warning when the non-top dialog closes? That would have given me an indication that I was closing them in the wrong order? I had to dig into the Wt code to figure out that the order of closing was the reason the cover was incorrectly shown/not shown depending on what I did.

About not doing exactly that in my application: I tried to explain that in the original description, but I'm going to give it a second shot now :), so here it goes:

I have a confirmation widget that is essentially a WDialog with one of it's parameters a boost::function to execute on confirmation (which automatically closes the dialog).
In one of my pages I can start a long process that I want to monitor with a popup showing essentially a 'tail -f', but before the start I want to user to confirm the starting of the process.
To accomplish '2' I binded a function that starts the process and creates a new Dialog showing the tail of the process. I gave the binded function as a parameter to my confirmation widget '1'. That didn't seem wrong to me then (and I would probably make the same mistake again). But this results in closing the confirmation popup right after creating the logging popup and thus a cover that is not there while it should have been.

I hope that clarifies why I didn't do it in the order that one would normally do this? But don't feel obligated to change this: using a server::post between the creation of the popups fixed my issue.

Kind regards,

Rob.

Actions

Copy link