[gelöst]Abfangen von "X" im WindowTitle

[ThorbenT]

Guten Tag,

bei mir liegt folgende Problematik vor:

Ich muss das Shließen meines Dialoges über den WindowTitle abfangen und diese auf die Methode des "Cancel" Button weiterleiten.

Die Methode prüft dann vor dem Schließen ob sich die eingelesenen Daten verändert haben ohne zu speichern und bietet dann die Möglichkeit diese vorher zu speichern.

mein bisheriger Versuch war:

void xy::reject()
{
closedialog();
}

Ich denke mal das "reject()" nicht funktioniert.
Gibt es denn bei Qt eine Möglichkeit das besagte Schließen des Dialogs zu
verhindern?

Noch zur Info:

Ich bin neu in der C++/Qt Welt
Nutze - Qt
- Visual Studio 2005

Hoffe mir kann da einer weiterhelfen

Grüße
ThorbenT

[Andy2211]

Hallo,
ich verstehs grade nicht 100%tig.

Du willst also beim Schließen eine Methode ausführen?
Oder beim Klicken auf den Cancel - Button?

Gruß,
Andy

[ThorbenT]

Beim klicken des Cancel Button wird geprüft ob die eingelesenen Daten verändert wurden ohne zu speichern. Wenn das der Fall sein sollte wird eine MessageBox ausgegeben, die einem die folgende Möglichkeiten gibt:

-Speichern und Schließen
-Schließen
-Abbrechen

Das selbe soll auch beim Schließen im WindowTitle geschehen, daher dachte ich mir das ich das Schließen des WindowTitle abfange und das klicken des "X" so ausführe als wäre der Button "Cancel" geklickt worden.

[Andy2211]

Hi,
du kannst das Event abfragen:

Code: Alles auswählen

bool guiclass::event(QEvent* event){
	QDialog::event(event);

	if(event->type() == QEvent::Close){
		//do something
	}

	return true;
}

Für QMainWindow funktioniert das, bei QDialog warscheinlich auch, habs aber nicht getestet. Du darfst nur den oberen Aufruf dder event() Funktion nicht vergessen, da sich auf deinem Dialog sonst nichts mehr tut.

Gruß,
Andy

[ThorbenT]

vielen dank für die schnelle Hilfe.

[macman]

Guck mal in der Forensuche. Alle Events zu checken, ob ein closeEvent dabei ist, halte ich für übertrieben. closeEvent überschreiben reicht da völlig.

[Andy2211]

Hi,
stimmt, hab ich total vergessen, dass das auch geht
Aber es wäre ja so viel zu einfach

Gruß,
Andy

[RHBaum]

Ich muss das Shließen meines Dialoges über den WindowTitle abfangen und diese auf die Methode des "Cancel" Button weiterleiten.

Die Methode prüft dann vor dem Schließen ob sich die eingelesenen Daten verändert haben ohne zu speichern und bietet dann die Möglichkeit diese vorher zu speichern.

Wobei das Ziel immer noch fragwuerdig bleibt ...

warum gibt es den "x" Button am Fenster ?
Der M$ Styleguide meint, das er zum schliessen des Fensters ohne jegliche weitere userinteraction dient.

sauberes M$ verhalten waer demnach ....

user drueckt "cancel" -> der Dialog darf mit der "sind sie sich wirklich sicher ?" Masche nerven.
user drueck das x an der Fensterdeko -> User ist sich sicher das er alles verwerfen will -> schliessen ohne nachfrage ohne zu speichern.

fuer fenster wo du zum schliessen unbedingt noch infos brauchst, sollte man die x Schaltflaeche demnach ned anbieten ...

Fuer kde und gnome sollte es aehnliche Styleguides geben ...

Ciao ...

[macman]

warum gibt es den "x" Button am Fenster ?
Der M$ Styleguide meint, das er zum schliessen des Fensters ohne jegliche weitere userinteraction dient.

Welches Programm macht denn das? Mir ist kein Programm bekannt, das Änderungen ungefragt verwirft. Von Microsoft schon gar nicht

[myme]

Mag ja sein, dass Windows sich das so vorstellt. Bei meinen Programmen:
- (X) überprüft auf geänderte Werte, falls geändert "ja/nein/abbruch" Orgie
- Cancel bricht den Dialog direkt ab, ohne Nachfrage

Das (X) ist relativ unspeziefisch und liegt außerdem nur wenige Pixel neben der Maximierenschaltfläche, wo Fehlbedienungen häufig auftreten. Hier ohne Nachfrage einfach das Fenster zu schließen ist sehr ärgerlich.

[RHBaum]

Welches Programm macht denn das? Mir ist kein Programm bekannt, das Änderungen ungefragt verwirft. Von Microsoft schon gar nicht

Microsoft macht scheinbar einen Unterschied zwischen Hauptdokumenten und Einstellungsdialogen. Da hier die Rede von

Shließen meines Dialoges

ist, glaube ich nicht das es sich bei den Daten um "Dokument" handelte.

- (X) überprüft auf geänderte Werte, falls geändert "ja/nein/abbruch" Orgie
- Cancel bricht den Dialog direkt ab, ohne Nachfrage

Das (X) ist relativ unspeziefisch und liegt außerdem nur wenige Pixel neben der Maximierenschaltfläche, wo Fehlbedienungen häufig auftreten.

Prinzipiell geb ich dir recht was die "Sicherheit" der Daten anbelangt.

Aber man kann sich sicher auch streiten drüber, welche Form der Fehleingabe wahrscheinlicher ist! Das "x" statt dem "_" auf der Fenster Dekoration zu treffen, oder ausversehen <ESC> zu treffen.

Wenn die Daten wirklich wertvoll sind, wird man beides wahrscheinlich absichern (unabhaengig vom Style Guide).

Erwarten von ner Anwendung unter diesem Aspekt wuerd ichs eher andersrum, weil <ESC> trifft man eher ausversehen als <ALT> <F4>.

Wenn Du "viel zu Bearbeiten" hast, laesst du das wirklich in einem Dialog, und nicht in einem Applications-Fenster oder so machen ?
Der einzigste Fall der mir im Moment einfaellt, wo man in Dialogboxen bissi mehr einpflegt, sind die Wizards. aber da verhaelt sich M$ konsequent, und bei Fehlbedinung sind die Daten auch weg.

Ciao ...

[myme]

Aber man kann sich sicher auch streiten drüber, welche Form der Fehleingabe wahrscheinlicher ist! Das "x" statt dem "_" auf der Fenster Dekoration zu treffen, oder ausversehen <ESC> zu treffen.

In meinen Programmen ist Escape immer äquivalent zum Schließen über (X), da die Escape Taste genauso unspeziefisch ist wie der Fensterschließmuskel (X).
- ESC und (X) werden via closeEvent abgehandelt
- Cancel via Reject
- OK via Accept