Laden...

Per Control.Invoke aufgerufenes Form.ShowDialog hält Thread an

Erstellt von inflames2k vor 12 Jahren Letzter Beitrag vor 12 Jahren 3.340 Views
inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 12 Jahren
Per Control.Invoke aufgerufenes Form.ShowDialog hält Thread an

Hallo,

in einem Thread werden über einen Webservice Informationen zum Anzeigen zyklisch abgerufen. Dies passiert innerhalb eines Threads. Kommen neue Einträge hinzu, die angezeigt werden sollen, wird im GUI Thread ein Form mittels ShowDialog angezeigt.

ShowDialog deshalb, weil weitere x-Einträge vorhanden sein können, die nacheinander angezeigt werden sollen.

Nun ist es aber so, dass der Thread der die Daten ermittelt bei ShowDialog() ebenfalls nicht weiterarbeitet.

Woran liegt das? Sollte dieser nicht unberührt davon bleiben?

Hinweis von herbivore vor 12 Jahren

Unabhängig von der konkreten Frage, sollte man mit modalen Dialogen sehr sparsam umgehen oder besser ganz die Finger davon lassen, siehe Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte].

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

S
443 Beiträge seit 2008
vor 12 Jahren

grundsätzlich ja, wartet er auf eine Antwort vom Gui Thread? (Antwort vom User)

mbg
Rossegger Robert
mehr fragen mehr wissen

Montag morgen ist die beste Zeit um eine erfolgreiche Woche zu beginnen

inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 12 Jahren

Der Thread? Nein.

Grundsätzlich arbeitet er wie folgt:
-> 1) Abruf & Prüfung Etwas zum anzeigen vorhanden?
-> nein - XXX Sekunden warten
-> ja - Anzeige des Eintrags
-> Erneut Schritt 1

Aber mir scheint als wäre das etwas anders:

-> 1) Abruf & Prüfung obs angezeigt werden muss
-> nein - XXX Sekunden warten
-> ja - Anzeige Eintrag
--------------
-> Thread Pause solang dialog offen
-> Erneut schritt 1

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

S
443 Beiträge seit 2008
vor 12 Jahren

Was sollte der Thread machen, während der Dialog offen ist?

// EDIT
Wie sagt der Thread der GUI das was angezeigt werden soll? (Code)

mbg
Rossegger Robert
mehr fragen mehr wissen

Montag morgen ist die beste Zeit um eine erfolgreiche Woche zu beginnen

inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 12 Jahren

Was der Thread während dessen machen soll? Weiter auf Anzuzeigende Meldungen prüfen.

im Code sieht das wie folgt aus:


private void CheckForNotifications()
{
    while(!_bStop)
    {
        List<Notification> notifications = new List<Notification>();
        notifications = _webserviceClient.GetNotifications(DateTime.Now);
 
         if(notifications.Count > 0)
         {
              this.ShowNotifications(notifications);
         }
         // Thread.Sleep here cause its an ce application
         Thread.Sleep(1000);
    }
}

private void ShowNotifications(List<Notification> notifications)
{
   if(this.InvokeRequired)
   {
       this.Invoke(new ShowNotificationDelegate(ShowNotifications), notifications);
       return;
   }

   foreach(Notification notification in notifications)
  {
         notificationForm = new NotificationForm();
         notificationForm.Notification = notification;
         notificationForm.ShowDialog();
  }
}

Ist jetzt unvollständig aber das notwendigste. -> Alles unwichtige hab ich heraus genommen.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

U
1.688 Beiträge seit 2007
vor 12 Jahren

Hallo,

"Invoke" blockiert solang die Funktion im GUI-Thread nicht zurückkehrt (s. Dokumentation).

S
443 Beiträge seit 2008
vor 12 Jahren

jep, BeginInvoke wird wahrscheinlich die Methode Deiner Wahl sein

mbg
Rossegger Robert
mehr fragen mehr wissen

Montag morgen ist die beste Zeit um eine erfolgreiche Woche zu beginnen

1.820 Beiträge seit 2005
vor 12 Jahren

Hallo!

  1. Mit ShowDialog wird der Thread solange "blockiert", bis die Form wieder geschlossen wird.
  2. Anstatt Invoke (synchron) sollte man evtl. BeginInvoke (asynchron) verwenden, wobei ich nicht weis, was in der aufrufenden methode passiert.
  3. Sollte man evtl. das gesamte Anzeige-Konzept überdenken.

Ich beschreibe mal das Problem mit eigenen Worten, damit wir nich aneinander vorbeireden:
Über einen WebService werden Daten in zeitlich festgelegten Intervallen abgerufen. Diese sollen lokal in einer Form angezeigt werden. Zusätzlich sollen neue Daten in der Form angezeigt werden, wenn diese vorliegen und die Form noch geöffnet ist.

Soweit korrekt?

Frage 1: Sollen die Daten erst abgerufen werden, wenn die Form geöffnet wird?
Frage 2: Muss die Form zwingend modal sein?

In diesem Fall würde ich die Form um eine eigene Methode oder ein Event erweitern, welcher/m die Daten übergeben werden. Somit hättest du eine weitere Kapselung, da sich ja im Laufe der Zeit vielleicht die Darstellung ändern könnte, was die Datensammlungs-Komponente aber ja nicht interessieren sollte.

Der Thread würde lediglich die Methode / das Event aufrufen und dieses könnte mittels BeginInvoke die Aktualisierung anstoßen.

Nobody is perfect. I'm sad, i'm not nobody 🙁

inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 12 Jahren

Hallo tom-essen, bis auf eine Kleinigkeit stimmt deine Ausführung so.

Der Vollständigkeithalber geh ich mal näher ins Detail:

Über den Webservice werden in einem festgelegten Intervall Daten zur Anzeige abgerufen. - Dabei sollen nicht alle Zeitgleich visualisiert werden sondern nacheinander.

Es kann zum Beispiel sein, dass nach dem ersten Durchlauf 10 Notifications da sind, die angezeigt werden sollen. - Nach Bestätigen der ersten soll die zweite angezeigt werden und so weiter...

Jede Meldung hat zusätzlich einen Status. Wird beim nächsten abruf die aktuell angezeigte Meldung mit einem anderen Status ermittelt, soll die Meldung wieder ausgeblendet werden.

Modal soll der Dialog deshalb sein, weil der Benutzer während der Dialog offen ist nicht weiterarbeiten darf (außer auf dem Dialog).

Ich werd mal BeginInvoke probieren.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo inflames2k,

Dabei sollen nicht alle Zeitgleich visualisiert werden sondern nacheinander.

Es kann zum Beispiel sein, dass nach dem ersten Durchlauf 10 Notifications da sind, die angezeigt werden sollen. - Nach Bestätigen der ersten soll die zweite angezeigt werden und so weiter...

klingt für mich nach schlechtem und benutzerunfreundlichem Design. Ich möchte als Benutzer bestimmen, was ich wann tun möchte und nicht von einem Programm vorgegeben bekommen, was ich in welcher Reihenfolge zu tun habe.

Ich habe schon im Moderationshinweis im ersten Beitrag ganz generell darauf hingewiesen, dass modale Dialoge out sind (siehe Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte]). Jetzt hole ich das für den konkreten Fall nach.

Und sage bitte nicht, es würde nicht anders gehen. Es geht immer anders, wenn man will. Und auch Kunden kann man oft überzeugen, wenn man ihnen die Sache mal richtig vor Augen führt.

herbivore

S
443 Beiträge seit 2008
vor 12 Jahren

klingt für mich nach schlechtem und benutzerunfreundlichem Design. Ich möchte als Benutzer bestimmen, was ich wann tun möchte und nicht von einem Programm vorgegeben bekommen, was ich in welcher Reihenfolge zu tun habe.

...

Und sage bitte nicht, es würde nicht anders gehen.){gray}

Hallo herbivore,

ich habe das schon sehr oft von dir gelesen, soweit kann ich Deine Argumentation auch verstehen da man ja mit den "neuen" Programmier-Möglichkeiten auch "neue" Programm-Möglichkeiten erhält welche man auch nutzen soll.

Aber gleich von schlechten Design zu reden halte ich für vorschnell, vorallem, da Du nicht weist von wem die Idee kam (Kunde?) bzw. was das Fenster eigentlich anzeigt.

Wenn ich Deine Vorstellungen richtig verstehe (wenn ich hier falsch liege ist der ganze Beitrag obsolete), stellst Du Dir eine moderne Anwendung so vor dass alle Meldungen als eigene Tabs in einer "MDI" erscheinen und er Benutzer sich aussuchen kann ob er sich jetzt darum annimmt ... oder auch nicht.

Nur es gibt manche Workflows im Tagesablauf eines Benutzers die die ganze Anwendung blocken kann.
Ich schreibe Börsendatenimportsystem für Grossbanken. Und wenn da ein User eine Aktie bearbeitet (die Informationen dazu) und er beim Eingeben der Daten einen Fehler macht, dann hat er sich zum Kuckuck sofort darum zu kümmern warum z.b. die Validierung der Preise fehlschlägt. Er hat ein Lock auf die Aktie und jeder andere Teil des Systems steht. Es kann ja nicht exportiert werden wenn es gerade bearbeitet wird. Dann steht eine 64 Core Maschine und wartet bis der liebe User sich entscheidet die Fehler zu bearbeiten. Nö das geht einfach nicht. Da muss der ValidationErrorDialog aufpoppen und er hat das JETZT zu machen.

Was ich damit sagen will, nur weil ein blocking Dialog aufpoppt es noch lange kein schlechtes Design ist.

mbg
Rossegger Robert
mehr fragen mehr wissen

Montag morgen ist die beste Zeit um eine erfolgreiche Woche zu beginnen

6.911 Beiträge seit 2009
vor 12 Jahren

Hallo spike24,

hier hast du herbivores "Kritik" wohl falsch verstanden. Umgemünzt auf dein Beispiel heißt das dass zwar an prominenten Stelle die Fehlermeldung kommt so dass der Benutzer diese nicht übersehen kann. Aber eben nicht per modalem Dialog, sondern so dass die Eingabemaske weiterhin reagiert. Warum? So kann der Benutzer den Fehler korrigieren und sieht dabei die Fehlermeldung - er weiß also ganz genau welchen Fehler er beheben muss. Mit einem ShowDialog den er wegklickt um dann den Fehler zu bearten muss er sich den Fehler erstmals merken. Und DAUs kennst du ja 😉

Stell dir auch Visual Studio vor das beim Kompilieren für jeden Fehler eine MessageBox anzeigt oder sonst was modales -> das Fehlerbeheben wäre eine Katastrophe.
Es gibt also andere bessere Möglichkeiten. Das meinte herbivore.

Ich schreibe Börsendatenimportsystem für Grossbanken.

Das erklärt einiges zur Wirtschaftslage 😁 - SCNR (nicht böse gemeint) -

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

S
443 Beiträge seit 2008
vor 12 Jahren

Ich habe mich im grossen und ganzen gegen "schlechtes Design" gewehrt, so pauschal kann man das nicht einfach sagen. Ich stimme aber der Aussage zu, dass es immer ein besseres Design gibt.

Das erklärt einiges zur Wirtschaftslage 😄 - SCNR (nicht böse gemeint) -

erwischt, ja, ich wars 😉

mbg
Rossegger Robert
mehr fragen mehr wissen

Montag morgen ist die beste Zeit um eine erfolgreiche Woche zu beginnen

inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 12 Jahren

Bei den Meldungen handelt es sich um wichtige Betriebsmeldungen, die der Benutzer bestätigen muss bevor er weiter arbeiten kann. Es handelt sich dabei um bestimmte Maschinenstatus, z.B. gesperrt etc. nun kann er an der Maschine da sie gesperrt ist nicht arbeiten und sollte schnellst möglich den Fehler beheben.

Ich stimme ja zu, dass modale Dialoge meist nicht das richtige Mittel sind. - Aber hier denke ich ist es eine der optimalen Lösungen.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo spike24,

erstmal habe ich gesagt, "das klingt nach schlechte Design" und nicht "das ist schlechtes Design". Natürlich kann es in speziellen Situationen immer gute Gründe für eine abweichende Vorgehensweise geben, wobei man es sich jedoch auch nicht zu leicht machen sollte und immer sehr kritisch prüfen sollte, ob die Gründe auch wirklich substantiell und ausreichend sind und es tatsächlich keine Alternative gibt. In allgemeinen Fällen bleibe ich dabei, dass es nicht mehr zeitgemäß ist, den Benutzer (unnötig) zu einer bestimmten Reihenfolge zu zwingen. Dazu gehört für mich insbesondere, dass man modale Dialoge (und vor allem MessageBoxen) weitestgehend oder ganz vermeidet.

Das bedeutet jedoch nicht, dass MDI die Alternative ist. Von MDI (im Sinne der Vorgaben von Microsoft) halte ich ebenfalls nicht viel. Ich bin ein Fan von eigenständigen, frei auf dem Desktop positionierbaren Fenstern. Das genauer zu beschreiben würde hier den Rahmen sprengen.

Dass man dem Benutzer Assistenten und andere Hilfen anbieten kann, die in an die Hand nehmen, wenn er selber keine Vorstellung von einer sinnvollen Reihenfolge hat, ist unbestritten. Dem Benutzer Freiheiten zu lassen, bedeutet natürlich nicht, ihn mit der einer Masse an Möglichkeiten zu überfordern und alleine zu lassen.

Das nur unmittelbar zu deinen Fragen. Damit sollte dieses Offtopic-Thema in diesem Thread auch behandelt sein. Sonst bitte PM ans Team und wir können das auch abteilen.

herbivore