Qdialog im Konstruktor beenden

[pospiech]

Ich lade im Konstruktor eines Dialogs eine DLL. Wenn ich nun feststelle das diese DLL unsinnige Werte zurückgibt (in meinem Fall das keine Geräte angeschlossen sind) möchte ich eine Warnung ausgeben und den Dialog direkt wieder beenden.

Wenn ich jetzt allerdings close() aufrufen, dann passiert gar nichts. Und der Dialog wird trotzdem angezeigt.

Wie erreiche ich daher dass der Dialog nicht angezeigt wird und direkt wieder der destruktor aufgerufen wird?

Matthias

[upsala]

Man kann kein Object zerstören, während es noch erstellt wird. Verwende das Show-Event oder noch besser das Polish-Event, initalisiere dort und löse dann im Bedarfsfall das Close-Event aus...

[pospiech]

Man kann kein Object zerstören, während es noch erstellt wird. Verwende das Show-Event oder noch besser das Polish-Event, initalisiere dort und löse dann im Bedarfsfall das Close-Event aus...

Das polishEvent habe ich nicht gefunden in der Doku. Ich habe dafür in dem showEvent ein close implementiert.

Konkret wird eine funktion in showEvent aufgerufen die im Bedarf ein close aufruft. Das sieht dann so aus:

Code: Alles auswählen

void DialogPIMove::InitDialog()
{
	
	m_iControllerCount = TranslationStage.getControllerCount();
	if (m_iControllerCount  == 0)
	{
		int ret = QMessageBox::warning(this, "Warning",
                   "No Ttanslationstages found. Total number is 0",
                   QMessageBox::Cancel);
		OnBnClickedButtonClose();
	}
	else
	{
...

}

void DialogPIMove::OnBnClickedButtonClose()
{
	if (TranslationStage.DllLoaded())
	{
		if (TranslationStage.isConnected())
			TranslationStage.StopMotionHereAndAbort();
		TranslationStage.unloadDLL();
	}
	this->close();
}

Nach dem close wird allerdings in der Funktion ab dem 'else' trotzdem weitergearbeitet. Wie habe ich das nun zu verstehen? Ich möchte ja, dass der Dialog wirklich beendet wird.

Denn jetzt habe ich einen abgestürzten Dialog, der sich nicht mehr über die GUI beenden lässt.

Matthias

[upsala]

Doku von QEvent nicht gelesen? Und woher sollen wir wissen, was die Methode getControllerCount() macht?

[Deever]

Ich lade im Konstruktor eines Dialogs eine DLL.

Ah ja? Und warum? Worin besteht der Sinn, Applikationslogik mit GUI-Code zu verbasteln?

Denn jetzt habe ich einen abgestürzten Dialog

LOL, naja, solange der Rest des Programms ja nicht abstürzt?

Gruß,
/dev

[pospiech]

Doku von QEvent nicht gelesen? Und woher sollen wir wissen, was die Methode getControllerCount() macht?

Nein hatte ich nicht gelesen, hat mich jetzt aber auch nicht weitergebracht, da mir unklar ist welcher Teil der Doku für mich relevant sein sollte. Was 'getControllerCount()' genau macht ist im Prinzip egal, da hier nur der Fall 'getControllerCount() == 0' eine Rolle spielt.

Ich lade im Konstruktor eines Dialogs eine DLL.

Ah ja? Und warum? Worin besteht der Sinn, Applikationslogik mit GUI-Code zu verbasteln?

Ich könnte die DLL auch so laden. Genutzt wird sie aber nur innerhalb des Dialogs. Aber das ist nicht das Problem. Denn ich greife im Dialog auf Funktionen der DLL zurück, die mir sagen ob der Dialog überhaupt sinnvolle Werte anzeigen kann. Und dann stelle ich fest das dem nicht so ist.

Denn jetzt habe ich einen abgestürzten Dialog

LOL, naja, solange der Rest des Programms ja nicht abstürzt?
[/quote]
Mag lustig sein, ist aber so.

Ich habe jetzt die Logik vor das Darstellen des Dialogs gepackt.

Code: Alles auswählen

void MainWindow::OnPiMove()
{
	if (!TranslationStage.DllLoaded())
		TranslationStage.LoadDLL();
	dlgPiMove = new DialogPIMove(this);	
	if (TranslationStage.getControllerCount()  == 0)
	{
		int ret = QMessageBox::warning(this, "Warning",
                   "No Translationstages found. Total number is 0",
                   QMessageBox::Cancel);
		TranslationStage.unloadDLL();
		dlgPiMove->close();
	}
	else
	{
		dlgPiMove->show();
		dlgPiMove->activateWindow();
	}
}

[RHBaum]

In deinem beispiel haengst du das widget (dialog) in die QT hirarchie ein ...
vorteil: du brauchst es ned selbst zu loeschen ...

der vorteil wird aber bei dir zum nachteil ....
QT cachts die widgets ... d.h die werden zwar geladen, aber teilweisse ned wieder entladen .... sondern nur gehidet ... der dialog wird also "irgendwann" spaeter erst zerstoert.

Umgehen kannst das wenn die QT den dialog ned verwalten laesst ...
grad bei dialogen benutzen wir meist folgende Syntax:

Code: Alles auswählen

QXYZDialog diag(this);

if(diag.exec() == qt::Accept) 
{
     ..... 
}

in deinem fall waers wahrscheinlich sogar noch besser, dem dialog einfach irgend ne schnittstelle auf funktionen zu deiner Dll mitzugeben ...
Die funktion der dll schoen kapseln, und vor dem abrufen abchecken, und erst wenn deine bedingung erfuellt ist, ueberhaupt den dialog anzulegen ...

Grade Dlls von "fremdherstellern" zu abstrahieren, macht sich auf dauer bezahlt ....

Ciao ...