Hallo zusammen,

ich hätte eine (Anfänger-) Frage zu Software-Architektur im Groben.
Ich beschreibe zunächst kurz meine Problemstellung:
In Form1 (eine Art MDI) eine Buttonleiste links, Toolstrip oben und dem Rest der Form ein Panel mit Dock.Fill. In dem Panel wird FormA, B oder C geöffnet (je nachdem welcher Button auf Form1 betätigt wird).
Nun gibt es in FormB mehrere Label, welche je nach Wert (wird aus einer SPS ausgelesen), die Farben ändern (rot,gelb,grün, wie eine Ampel).

Nun zur eigentlichen Frage:
Auf Form1 befindet sich auch so ein Label mit Farbwechsel, sodass, auch wenn FormC oder FormA geöffnet sind, die Zustände im Blick behalten werden können. Einfache Logik: Wenn eins der Label gelb ist, soll das Label auf Form1 auch gelb werden; wenn eins rot ist, soll das Label auf Form1 auch rot werden.

Wie oder besser wo würde man die "Auswertung" der Werte und die Farbwechsel des Labels programmieren? In FormB wäre es Blödsinn, da man sonst dasselbe noch einmal in Form1 machen müsste...

Wird soetwas in einem extra Modul "ausgelagert" und dann nur in den entsprechenden Forms aufgerufen?

Vielleicht noch kurz zum Umfang: es wären ca. 60 Label auf FormB

Danke euch beiden erst einmal für die schnellen Antworten..

@Naifu: Ich wäre folgendermaßen an die Sache rangegangen. Auf FormB meine Werte aus der SPS in ein Array packen und dann eine "Ampel"-Sub aufrufen, welche je nach Wert, die entsprechende BackColor für das jeweilige Label ausspuckt.
Auf Form1 kann ich nun nicht einfach fragen ob eins der 60 Label gelb oder rot ist, da FormB im schlimmsten Fall gerade geschlossen ist. Also müsste ich alles noch einmal (ein bisschen angepasst) schreiben.
Wie würde das mit dem Event von einer in die andere Form theoretisch funktionieren?

@Akanel: Es soll nur auf der Hauptform (Form1) im Toolstrip angezeigt werden (ein Label, wechselt einfach nur die BackColor). Wenn der Nutzer nun sieht, dass das Label gelb ist, kann er FormB öffnen und sehen, von welcher der 60 einzelnen Label das Problem kommt. Viel mehr Forms sollen es eigentlich nicht werden, zumindest nicht mit dem "Ampelsystem".

@Naifu: ich meine die prinzipielle Funktionsweise der Events zwischen den Forms. Hinter der Ampel Sub steckt kein Geheimnis. Es wird der aktuelle Wert (aus der SPS), ein vom User einstellbares (Wechsel-)Intervall, ein Grenzwert und das dazugehörige Label übergeben. Dann wird lediglich verglichen ob der aktuelle Wert kleiner als das Intervall-Grenzwert ist, dann wird Label.Backcolor=grün, wenn der wert zwischen Intervall-Grenzwert und Intervall liegt wird es gelb und alles über dem Intervall rot.

Zusammenfassen lässt sich nicht mehr viel. Es geht um eine relativ große Anlage mit vielen Werkzeugen. Auf der Hauptform (Form1) soll nur schnell für den Bediener ersichtlich sein, ob ein Werkzeug (der 60 vorhandenen) gewechselt werden muss, also wenn das Label bspw gelb ist. Dann würde der Bediener im Optimalfall FormB aufrufen und erkennen können, welches Werkzeug betroffen ist.

@VaporiZed: Genau das war meine Ausgangsfrage. Also als "Profi" würde man eher die beiden Forms die Anzeige übernehmen lassen und den Code in einem (im Hintergrund agierenden) Modul verstecken? Und dann rufen die Forms (in meinem Fall Form1 und FormB) nur einzelne Subs des Moduls ab, oder?

@ErfinderDesRades:
Ich habe mich tatsächlich nach deinen Tutorials zum typisierten Dataset gerichtet. Ich versuche noch ein bisschen was zur Problematik zu schreiben, ohne dass es zu weit in die Maschinenbau-Richtung geht.
Die Maschine besteht aus 5 Linien. Jede Linie hat ca. 20 Stationen. An jeder Station gibt es x Werkzeuge, welche, mehr oder weniger regelmäßig, gewechselt werden.
Ich habe mir also ein Dataset mit 4 Tables erstellt: Strecke, Station, Werkzeug und Wechsel.

Strecke: ID(PKey), Name
Station: ID(PKey), Strecke-ID(FKey), Name
Werkzeug: ID(PKey), Station-ID(FKey), Name, Intervall
Wechsel: ID(PKey), Werkzeug-ID(FKey), Datum, Standzeit, Bemerkung

Ich hoffe das ist soweit der richtige Weg.
Das Problem ist, dass mir dein Tutorial, für das Programmieren gegen das typisierte Dataset, für meine Aufgabenstellung nicht sehr weitergeholfen hat.
Also habe ich, wahrscheinlich sehr umständlich, für jedes Werkzeug zwei Textboxen, zwei Buttons und eins von meinen ominösen "Ampel-Labels" dazu angelegt.
In TextBox1 wird der Wert aus der SPS ausgelesen (32Bit-Variable über OPC), der Button dazu löst ein AddWechselRow aus (mit aktuellem Datum und "Zählerstand" aus der Textbox). Diese durchgeführten Wechsel werden in einer anderen Form in einem DataGridView angezeigt (dort können dann auch noch Bemerkungen dazu eingegeben werden).
In TextBox2 wird das Wechsel-Intervall angezeigt und kann auch durch Eingabe + ButtonClick eingetragen werden (Table Werkzeug/Intervall). Derzeit mache ich das so, dass ich mir die WerkzeugRow per FindID raussuche, mit der dazugehörigen WerkzeugID hart eincodiert (also: blablabla.FindID(25) ). Theoretisch werden keine neuen Werkzeuge hinzugefügt. Deswegen ist das für uns ok. Es gibt bestimmt einen eleganteren Weg, aber den kenne ich (noch) nicht.
Zur Dataset-Geschichte hätte ich auch noch eine Frage: Gibt es eine Möglichkeit mit Befehlen a la "Select row where Name=xyz" ein offline (XML-) Dataset bzw eine Table davon zu "durchsuchen"?

Die "Variablen" aus der SPS werden als sogenannte OPC-Items angelegt. Mit Steuerungsname, Adresse, usw...
Bei diesem Programm greife ich auf 8 unterschiedliche Steuerungen zu. Mir ist noch nichts eingefallen, wie ich das etwas "automatisieren" könnte (eventuell in einen Array schmeißen, um per Schleife alle Werte zu holen?).
Ich kenne Varianten (>1000 SPS-Objekte), bei denen ein lokaler SQL-Express-Server dazu im Hintergrund läuft und eine DLL die Arbeit übernimmt (Quellcode leider nicht bekannt).

Ursprünglich wollte ich mir nur "Inspirationen" und Tipps zu Software-Architekturen für Programme solcher Art holen, ohne zu sehr ins Detail zu gehen, aber wahrscheinlich habe ich mich in meinem ersten Post etwas schlecht ausgedrückt.
Daher als direkte Frage: Hat jemand empfehlenswerte Links zu Artikeln rund um Software-Architektur (bestenfalls in Richtung meines Problems)?

Und vielen Dank für die Tutorials, ErfinderDesRades. Wirklich sehr gut erklärt, für Einsteiger in die Thematik wie mich.

@VaporiZed: Danke, ein Beispiel wäre super. Wenn ich deinen Post und den von ErfinderDesRades zusammennehme, weiß ich (glaube ich zumindest) langsam wo die Reise hingeht.