QDialog derived class doens't show until an event (mouse click etc).

[hdl]

I have a set of classes derived from QDialog, which I either call with show or exec. Under both circumstances the dialogs do not appear until an event arises. I would like the dialogs to appear without being triggered.

The dialogs are being created parentless.

The environment I am working with is the iphone simulator qt5.4.1.

Any ideas, please?

Huw

[anda_skoa]

Can you maybe rephrase what you are looking for?

I don't see how a dialog would magically know to appear without being told so by the program code in some form

Cheers,
_

[hdl]

I construct & call exec from the MainWindow. The dialog doesn't appear until an event of some kind occurs -- a mouse click, a key press etc.

void MainWindow:n_actionLetters_triggered()
{
if (pEditLetters == 0)
{
pEditLetters = std::shared_ptr<EditLetters>(new EditLetters(session_));
}
pEditLetters->setModal(true);
pEditLetters->exec();
int index = pEditLetters->getCurrentIndex();
if (index == static_cast<int>(indexOfCurrentLetterToDraw))
{
miniLetterPoints->recalc();
mainLetterPoints->recalc();
}
}

class EditLetters : public QDialog
{
Q_OBJECT
public:
explicit EditLetters(bootstrap::UserSession& s ,QWidget *parent = 0);
...
};


EditLetters::EditLetters(UserSession& s, QWidget *parent)
: QDialog(parent)
, ui(new Ui::EditLetters)
, session(s)
, m_accepted(false)
{
ui->setupUi(this);
setWindowFlags(Qt::CustomizeWindowHint | Qt::WindowStaysOnTopHint | Qt:ialog);

...
}

---

Added after 57 minutes:

If I override paintEvent for the dialog and set a breakpoint, I find that the dialog paint event does not arise until after the key press etc. I want the dialog to be painted when I call exec(). As far as I can see it is not doing so because of either 1) The dialog is hidden or out of focus in some way or 2) There's a bug.

void EditLetters:aintEvent(QPaintEvent* event)
{
QDialog:aintEvent(event);
}

[anda_skoa]

It should show up when you call exec().

exec() calls show() and starts a nested event loop which then should process the show event and make the dialog appear.

Make sure you pass your existing window as the parent to the dialog, so it gets associated correctly and not treated as an independent window and kept hidden by the system to avoid focus change.

Cheers,
_

[hdl]

No joy.

void MainWindow::checkCreateEditLetters()
{
if (pEditLetters == 0)
{
pEditLetters = std::shared_ptr<EditLetters>(new EditLetters(session_, this));
pEditLetters->setModal(true);
}
}

void MainWindow:n_actionLetters_triggered()
{
checkCreateEditLetters();
pEditLetters->exec();
int index = pEditLetters->getCurrentIndex();
if (index == static_cast<int>(indexOfCurrentLetterToDraw))
{
miniLetterPoints->recalc();
mainLetterPoints->recalc();
}
}

I see this behaviour on all the dialogs, occasionally (intermittently) showing correctly.

[anda_skoa]

Do you also get this when you run the application built for desktop OS X?

Cheers,
_

[hdl]

No, I don't get the problem when I run the application built for the desktop.

Would failure to handle (accept) events be an issue?

[anda_skoa]

No idea, sorry.
As you have experiences yourself on desktop, this is how it should work. Could be something iOS specific or a bug of Qt/iOS.

Cheers,
_

[ChrisW67]

Or a bug in the iPhone simulator. What does code do on an actual phone?

[hdl]

I haven't tried yet. I'll try deploying once I complete the first cycle.

What I noticed during development is that this is something that increased in frequency as I wrote more classes, so it may be a side effect of something else I'm doing.

[hdl]

Ok, I've resumed this project and am now working with a deployed app to an apple device (ipad mini 3). The behaviour I see is the same, so that's good with respect to the consistency of the simulator.

I've had time to read around a bit more to check I'm not using the objects inappropriately, and it looks like I'm using them in a conventional manner. What I have found that seems (initially at least) to help resolve the problem is a known issue with Qt 5.4, namely "Line edits inside dialogs might not be able to get focus and bring up the keyboard. The solution is to call QWidget::activateWindow() on the dialog after it has been shown" (see https://wiki.qt.io/Qt_for_iOS_known_issues).

So, if instead of executing a dialog I use:

pCfgGrid = std::shared_ptr<ConfigureGrid>(new ConfigureGrid(session_, l, this));
pCfgGrid->show();
pCfgGrid->activateWindow();

Then, that seems to resolve the problem for that particular dialog. I will see if this works consistently for all my use cases.

Best,
Huw

---

Added after 1 48 minutes:

I can confirm that the above approach works for my set up. Possibly there is something I'm missing with respect to the MainWindow class that would have made this easier, but I haven't found it.

Programatically, this means setting up callbacks for dialogs used, but I can cope with that.

Best,
Huw