Nvidia hat geschrieben:Aber wenn ich nun den Button mit accepted verbinde, dann heißt das der Dialog wird geschlossen.
Wenn aber das Feld leer ist, will ich ihn nicht schließen.
Dann verbinde ihn einfach nicht direkt mit accept() sondern mit einem eigenen SLOT, in dem du prüfst ob lineEdit leer ist. Falls nein -> rufe accept() auf. Falls ja - mach einfach nix
Code: Alles auswählen
Dialog::Dialog() {
// sonstwas
connect(okBtn, SIGNAL(clicked()), SLOT(on_okBtn_clicked()));
}
void Dialog::on_okBtn_clicked() {
if( !lineEdit->text().isEmpty() ) {
accept();
}
}
und deine zweite Codezeile will er nicht kompilieren.
Tjo, ohne Fehlermeldung kann dir dann keiner helfen. Und evtl. gleich den angemeckerten Code mitposten...
Aber eigentlich müsste er mit Dialog *dlg = new Dialog gebaut werden.
Weil er sonst gleich am Ende der Methode ist udn dann zerstört er den Dialog wieder.
Nein, eben nicht. exec() blockiert die aufrufende Funktion, in diesem Fall MainWindow::Dialog(), bis du accept(), reject() oder done() aufrufst.
Er baut den Dialog. Schaut ob er Accepted ist, was er natürlich nicht ist, weil er sofort nachdem er ihn gebaut hat prüft und dann ist er am Ende der Methode angekommen und zerstört den Dialog wieder.
Das versteh ich nicht so ganz.
Was heißt bei dir "Hat den Dialog gebaut"?
Und btw hab ich dein exec() gefunden. Das steht schon im Konstruktor von Dialog, was nicht so doll ist, weil du 1) von außen den return-Code nicht kriegen kannst, und 2) exec() im Konstruktor blockiert. Damit gilt dein Dialog-Objekt erst als vollständig erzeugt, wenn es schon wieder geschlossen wurde. Ich kenn den Standard aber zu wenig, um sagen zu können ob das irgendwo in undefiniertes Verhalten läuft oder nicht (denke eher nein, würde es aber trotzdem nicht machen).
