mehrere forms überwachen

[snook]

hey,

ich habe in meiner anwendung mehrere von TForm abgeleitete Formulare zu laufen, die über eine GPIB kommunikation mit verschiedenen Geräten kommunizieren. ich versuche gerade das ganze möglichst stabil zu gestalten. daher war mein erster gedanke, packe ich jedes Formular in ein thread und wenn eines abraucht, stört das mein maniform herzlich wenig. bevor ihr aufschreit, ich weiß das die vcl nicht thread sicher ist, daher habe ich das gleich wieder verworfen.

jetzt ist eure kreativität gefragt. gibt es eine möglichkeit mein gesamtes programm vor dem absturz zu bewahren, falls ein gerät (Form) aus irgendwelchen gründen abstirbt? bevor jetzt kluge kommentare zur programmierung der geräte kommen, für die bin ich nicht verantwortlich. die werden von anderen leuten erstellt und meine aufgabe ist es einfach nur diese in einem hauptprogram zu verwalten.

ich bin echt für jede hilfe dankbar

viele grüße

[Bernhard Geyer]

Der Ansatz hier überhaupt Formulare zu verwenden ist nicht sinnvoll.

Ich würde eine Klasse schreiben welche die Kommunikation übernimmt.
Dann eine Wrapperklasse welche die Klasse in einen Thread verlegt und für die Synchronisierung zuständig ist.
Das dann noch über entsprechende Basisklassen und Claas-Faktories so aufbauen das du an zentraler Verwaltungsstelle nicht mehr mit eigenheiten der Geräte zu tun hast sondern nur noch mit den Basisklassen arbeitest.

[Bummi]

Ich würde (und habe auch schon mehrfach) hier eine Threadbasierte/VCL-freie Basisklasse schreiben und Gerätespezische Ableitungen basteln.
Die Basisklasse kann beliebige auch virtuelle Methoden zur synchronisation beinhalten.

[snook]

okay wie würde denn das aussehen? ich kapsel die kommunikation in einen thread und kappe die gesamte grafische oberfläche ab?

[blackfin]

Ob die Kommunikation nun in einem eigenen Thread oder auch im Mainthread der Applikation laufen kann, kommt ja hauptsächlich drauf an, wie "blockierend" die Kommunikation an sich ist.
Aber die Kommunikation generell komplett von der GUI zu trennen, ist schon einmal eine sehr gute Idee
Dann kannst du nacher auch die GUI komplett austauschen, ohne dass du damit die Kommunikation beeinflusst.
Also den kommunkations-Code in eigene Klassen / Units kapseln oder auch in ein Datenmodul oder sowas in der Art, aber nicht in den Code der Form(s), denn das würdest du bald bereuen
Was meinst du eigentlich mit "wenn ein Gerät abstirbt"? Wenn die Kommunikation zusammenbricht? Das sollte generell mit der GUI gar nichts zu tun haben, sondern das soll die Kommunkations-Klasse abfangen können und eventuell dann eine Nachricht an die GUI senden können (oder die GUI pollt den Status, je nachdem was du genau vorhast), aber nicht so, dass dann die GUI abraucht

Ich habe so etwas auch schon einmal gemacht, ein Programm, dass drei Geräte überwacht.
Dazu habe ich mir erstmal die Kommunkations-Klasse für die Datenstrukturen und Befehle des Gerätetyps an sich geschrieben, im Programm dann selbst ein Datenmodul, das Instanzen dieser Geräte erzeugt / registriert und die Kommunkation der Geräte unter sich koordiniert. Die GUI-Forms an sich empfangen und senden dann nur noch Events vom Datenmodul, sind also reine Anzeigen und Empfänger für Tastatur-Mausangaben, die aber an die Logik-Schicht übergeben werden, die dann wiederum die Events feuert usw.

Somit habe ich dann drei Teile, die einzeln wartbar sind:
1) Kommunkations-Klasse für das Geräte-Protokoll (Klasse)
2) Logik-Schicht, die die Geräte-Instanzen koordiniert (Datenmodul)
3) GUI, die User-Eingaben annimmt und Meldungen anzeigt. (Forms)

Ausblick / Erweiterungen:
Was sich bei einer Geräte-Verwaltung nach meiner Erfahrung zudem noch anbietet, ist eine Art Scripting-API für das Programm und dessen Events, vor Allem dann, wenn es sich bei der Software oder sogar dem Gerät selbst um einen Prototypen handelt, bei dem noch nicht alle Gegebenheiten klar sind.
Dann macht es Sinn, die Events und Funktionen von Kommunkations- Logik- und GUI-Schicht, durch eine API-Schnittstelle nach Aussen hin zugänglich zu machen und die Verbindungen über Scripting zu realisieren. Das hat den Vorteil, dass der Kunde teilweise selbst festlegen kann, was angezeigt / gemacht werden soll, wenn ein bestimmtes Ereignis eingetreten ist. Gute Erfahrungen habe ich hier mit Lua gemacht, für Delphi bietet sich aber wahrscheinlich PascalScript mehr an.

[snook]

mit absterben meine ich so ziemlich alles was ein programm zum hängen bringen kann. ich bin für die gerätetreiber nicht verantwortlich, den schreiben die user je nach bedarf. da können dann so schöne sachen wie endlosschleifen mal ganz schnell passieren, oder es gibt AV's weil beim lesen der config was nicht hinhaut und der klassiker ist natürlich ein loses kabel, sodass die kommunikation zusammenbricht. das würde ich halt alles gerne vom gerätecontroller heraus abfangen können (dem ist es ja egal warum ein gerät nicht mehr reagiert).
danke schonmal für die struktur, die klingt ja ganz vernünftig