Chat

Kleiner "Fehler":

Wenn ich, während ich Connected & eingeloggt bin, kann ich auf Disconnect gehen. Login-LED bleibt weiterhin grün. Gehe ich dann wieder auf Connect, dann bin ich als wieder eingeloggt, aber ohne Username.

Vielleicht sollte man da einfach einiges in der Ablaufreihenfolge der Bedienung sperren.

Gruß, Jens

Anzeige

Ja, stimmt. Mache ich. Aber wie schon gesagt, jeder kann sich seinen Client so programmieren, wie er will

Hallo!

Nach den erfolgreichen Test habe ich viel Feedback von Benutzern bekommen. Nun habe ich jetzt eine neuere Version erstellt:

- Eingabe befindet sich jetzt unten (wie von anderen Chat-Programmen gewohnt)
- Neue Nachrichten werden nun unten angezeigt und "klettern" nach oben
- Enqueue Lossy (erst ab LV Version 8.6) mit meinem eigenen Buffer ersetzt, jetzt wird LV >= 8.2 unterstützt
- Doppelklick auf Usernamen fügt ihn in die Messageeingabe (Fokus und Cursor werden auf die Eingabe gesetzt)
- Connect wird automatisch beim Start gemacht und Disconnect am Schluss (vereinfachung)
- Logo verlinkt
- Button zum Senden wurde entfernt, das Senden passiert beim Value Change des Eingabeelements

Viel Spass beim Chatten!

Cool, der Server läuft immer noch. Das Ding scheint richtig robust zu sein

OFFtopic: warum auch nicht ? ehehhe... wir haben im LVF ja auch nur die besten Server ! (versteht sich...)

Offtopic: Warum nicht? Wenn die Codequalität so wie beim Client ist, wundert es mich schon (ein wenig)

Trotzdem danke für das Teil. Ich weiss... einem geschenkten Gaul...

Anzeige

Hi!

Kritik nehme ich gerne an. Was ist genau mit der Codequalität? Prinzip und Struktur sind IMHO übersichtlich.

Gruß, eg

P.S. habe zuerst geschrieben, dass das BD kommentiert ist, aber es ist erst kommentiert in dieser Version:
http://labviewportal.eu/download/file.php?id=2974

Da ist übrigens der Server mit dabei.

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

Das nenne ich aber gesunde Kritik.

1. Reconnect Logik. Ja, genau deshalb fliege ich ab und zu aus dem Chat raus. Da ich aber den Server nicht mit dem "ständigen" Verbindungsaufbau belästigen wollte, habe ich es so gelassen.

2. Das lasse ich LabVIEW mit dem automatischen Error-Handling machen. Der Error-Cluster ist ja dazu da (nur wenn angeschlossen), dass wenn ein Fehler auftritt, die nachfolgenden VIs nicht ausgeführt werden.

3. Stimmt, ich war einfach zu faul. Normalerweise müssen Typedefs in den Ordner "Common" kommen.

4. Ach, so weit habe ich nicht gedacht. Ich denke aber, es ist so schon ok.

5. Hmm, also Button klicken->Message an Server schicken->Message unten vom Server empfangen->Button setzen->Flag nach oben über User Event schicken. Im Endeffekt ist das Flag und nicht der Button entscheidend, der Button ist nur für die Anzeige da. Aber etwas Richtung Race Condition kann ich mir an dieser Stelle gut vorstellen.

6. Taste Logo ist gleichzeitig Control und Indicator. Das mag ich zwar nicht, aber wie sollte man beim Indicator Value Change abfangen? Oder wäre Mouse Klick besser? Habe noch nie Maouse Click Event bei Indicatoren abgefangen. Muss mal probieren.
Ansonsten ist es oben klar: Klick auf den Button->Sofort in den Urzustand wechseln. Da kann meinermeinung nach nichts schlimmes passieren.

7. Deinit.vi. Ist für mich so und so ok.

8. Get Date/Time String. Hm, wo was? Ein Bug? Hast du Info dazu?

Vielen Dank fürs Anschauen, eg

zu 8.
   
   
eine CAR habe ich dazu nicht