Meine Gedanken die ich beim drüberschauen hatte.
- Keine echte Reconnect Logik -> Bei Verbindungsabbruch beendet sich untere Schleife und obere läuft noch!?
- Mglw. sinnvoll in unterer Schleife Cases vertauschen, also zuerst auf Fehler prüfen und dann Daten interpretieren.
- Keine Typedefs bei shared Datentypen (Client <-> Server Messages). Macht keine Spass sowas zu pflegen, daß würde ich bei einem Codereview als KO Kriterium sehen
- Warum TCP Längeninfo nur als U16? Messages mit mehr als 65000 Bytes sind fürn Chat erstmal ausreichend. Könnten aber schnell zu wenig sein (z.b. beim Connect soll eine allgemeine, vom Server verwaltete, History übertragen werden.) Beim Senden könnte es jetzt also schon vorkommen, daß der gesendete String länger ist als die Längenangabe, da Stringlänge nicht begrenzt wird.
- Button "Login" und Client.lvclass halten beide die Info ob logged in? Wer hat recht? => Racecondition beim schnellem Klicken auf login. In unterer Schleife wird lokale Variable von Login geschrieben und zusätzlich wird ein User Event nach oben geschrieben. Warum beides?
- Taste Logo wird auch von beiden Schleifen beschrieben. Von der Art ist's eh eher eine Anzeige. Vorschlag: Umwandeln in Indicator und nur ein einer Stelle das Terminal direkt beschreiben (z.b. in Client User Event "connected") und Logo Value change Event in MouseDown ändern.
- Client Deinit.vi mglw. sinnvoll außerhalb der äußeren Casestruktur bzw. auch deren Fehlercase benutzen. Ist noch nicht wichtig, da im Init selbst nur Event Create selbst schiefgehen könnte, wenn das Programm allerdings wächst besteht immer die Gefahr, daß dort die Referenz geöffnet wurde und das Deninit nicht durchlaufen wird.
- (Nur als Hinweis: Das "Get Date / Time String" Primitive ist buggy und liefert ab ca. 2040 Mist)
Mit Kommentaren ist die Codequalität auch deutlich besser
P.S.
Sorry... ich weiß ich bin pingelig
