Verarbeiten von ESC-Sequenzen (VT100)

Hallo Nominas,

Zitat:- Weil ich mir nicht sicher bin, ob bei einer kompletten, neuen Seite nicht schneller ein neues Paket kommt.
…
- Weil das Problem nicht beim Lesen von der Schnittstelle liegt, sondern bei der Aktualisierung der Tabelle (und dort bei der Grafik)

Ich hatte dir schon vor knapp 3 Wochen ein Producer-Consumer-Schema nahegelegt!
Damit würdest du die serielle Schnittstelle ohne Code-Blockade bedienen können. Und das Lesen des seriellen Ports wäre nicht mehr von der Verarbeitung der Daten abhängig!

Zitat:- Weil ich denke, dass es sich so leichter auf andere Anwendungen anpassen lässt

Hier denke ich genau entgegengesetzt!
Warum sollte der Producer (Lesen der seriellen Schnittstelle) irgendetwas vom Consumer (Verarbeiten der Daten) wissen?
Warum sollte Consumer1 (Verarbeiten der Daten) irgendwie davon abhängig sein, wie Consumer2 (Anzeige der Daten) arbeitet?
Warum ist es einfacher, einen großen monolithischen Code-Block zu verwalten anstelle des Auftrennens in Producer-Consumer?
Warum ist es einfacher, diesen Codeblock anzupassen, wenn man "nur" den Consumer auf ein neues Datenformat anpassen müsste?

Das hat nichts mit LabVIEW an sich zu tun: Code sollte immer nur eine möglichst klar umrissene Aufgabe erfüllen! Und das sollte nicht sowas sein wie "seriellen Port schnell bedienen & gesamten Datenblob verarbeiten & komplizierte Anzeige aktualisieren" - das sind 3 ganz klar getrennte Aufgaben!

Zitat:- Weil sich die String-Anzeige nicht wie das klassische Terminal formatieren lässt (https://en.wikipedia.org/wiki/ANSI_escap...:Htop.png)

Jein. Du kannst durchaus den String formatieren - es ist nur ähnlich langsam wie bei der Tabelle…

Zitat:- Was ist, wenn ein anderer Anwender die Schriftart nicht hat?

Wenn ein User auf einem Standard-Windows keine Consolas-Schrift hat, dann hat der Admin geschlampt…
Genau deswegen gibt es Standard-Fonts auf jedem Betriebssystem!

Zitat:- Kann man die Größe einer String-Anzeige in Zeichen festlegen? Ansonsten kann man nicht sicher sein, dass die Anzeige immer passt.

Wenn du einen non-proportional font einstellst, dann stellst du damit auch die Zeichen-Größe (in Pixeln) ein!
Und dann kannst du auch sehr einfach bestimmen, wie groß dein String-Indicator (in Pixeln) sein muss, um die gewünschte Anzahl Zeichen darzustellen: simple Grundrechenarten reichen dafür…

Bei deiner Tabelle solltest du auch einen non-proportional font einstellen, sonst sieht die Anzeige sehr ungleichmäßig aus! (Ich bin bei sowas sehr empfindlich, ein UI MUSS gut aussehen und ein ordentliches UX bieten.)
Anderenfalls müsste ein Tabellenelement so breit sein, dass ein Buchstabe wie "W"/"Q"/"M" reinpasst, aber gleichzeitig würde ein "1"/"l"/"i" etc. sehr verloren darin aussehen…