Project

General

Profile

Actions

Bug #1512

closed

WDialog: cover not correctly set

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

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
11/06/2012
Due date:
% Done:

0%

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 #1

Updated by Koen Deforche almost 12 years ago

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

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 #3

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:

  1. 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).
  2. 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.
  3. 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 #4

Updated by Koen Deforche over 11 years ago

  • Status changed from Feedback to InProgress
  • Target version set to 3.3.1
Actions #5

Updated by Koen Deforche over 11 years ago

  • Status changed from InProgress to Resolved
Actions #6

Updated by Koen Deforche about 11 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF