Forum: PC-Programmierung besonders schnelles Richedit-Control


von H. D. (c3po)


Lesenswert?

Hallo

für eine Logging-Anwendung suche ich eine Möglichkeit Text sehr schnell 
ausgeben zu können, ich habe ähnliches vor längerem mit VC 6.0 gemacht, 
damals hat es noch gereicht, aber jetzt sind die Anforderungen an die 
Textausgabegeschwindigkeit gestiegen.

Wer kann mir da etwas empfehlen?

Achja, nach Möglichkeit sollte das ganze auf einem 1-Core System so 
funktionieren, dass Empfang, Auswertung und Ausgabe gleichzeitig machbar 
sind ohne dass das System stehen bleibt und ohne dass die Anzeige noch 
stundenlang nachscrollt nachdem nichts mehr empfangen wird. Die Ausgabe 
sollte in Farbe möglich sein.

ich sage schon einmal Danke

Gruß
H.D.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Welchen Sinn hat die besonders schnelle Ausgabe von Text? Das kann doch 
eh' keiner mehr lesen. Auch verbrät sowas sämtliche zur Verfügung 
stehende Rechenleistung.

Sinnvoller wäre die Darstellung des jeweils letzten Pufferinhaltes, wenn 
zeilenorientierter Text darzustellen ist, wäre ein ListView, genauer ein 
virtueller ListView wesentlich sinnvoller. Und wenn Du daraus einen 
OwnerDraw-ListView baust, kannst Du auch Text mit verschiedenen 
Attributen wie Farbe etc. ausgeben.

Was ist die Anwendung, wozu soll das ganze gut sein?

von H. D. (c3po)


Lesenswert?

Wie ich bereits sagte soll es ein Datenlogger werden, der mehrere 
Eingangsstreams hat diese etwas aufbereitet und dann ausgibt.

virtuelles Listview könnte man nehmen, die frage ist nur ob es schnell 
genug ist für meinen Zweck.

Danke für den Tipp

Fällt sonst noch jemandem etwas ein wie ich es umsetzen könnte oder was 
ich benutzen kann ?

von Ralf (Gast)


Lesenswert?

Ein Logger wird bei der direkten Ausgabe aber immer hinterher hinken, 
weil er primär eine andere Aufgabe hat - nämlich loggen, nicht ausgeben.

Ralf

von H. D. (c3po)


Lesenswert?

wohl wahr, allerdings wenn du zum Zeitpunkt 0 alle Eingänge abziehst und 
du siehst dass die Ausgabe noch eine Minute mit ausgeben beschäftigt 
ist, dann ist das auch nicht sinn und zweck der Sache
nachlaufen ok aber der Nachlauf sollte konstant sein und nicht abhängig 
sein von der Länge der Loggingzeit.

Nachtrag: seine primäre Aufgabe sind nicht nur das loggen sondern das 
zeitgleiche Ausgeben der bearbeiteten Log-Daten in Echtzeit.
zumind. so meine Forderung ;-)

Natürlich darf es nicht so umgesetzt sein, dass der Logger warten muss 
bis die bearbeiteten Daten ausgegeben wurden ...

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Das schnelle zeitgleiche Ausgeben in Echtzeit ist unnötig.
Sollten wirklich alle Daten wenigstens einmal auf dem Bildschirm zu 
sehen sein, begrenzt bereits die Bildwiederholfrequenz die 
Datenerfassungsrate.

Angenommen, das Logfenster kann 40 Einträge lesbar darstellen (Parameter 
hier: Schriftgröße und Bildschirmauflösung), und das ganze wird auf 
einem üblichen TFT-Monitor ausgegeben, dann können nicht mehr als 1200 
Einträge pro Sekunde erfasst werden.

Das ist sinnlos, außerdem kann das kein Mensch mehr lesen.

Es genügt also, den Bildschirminhalt asynchron zum eigentlichen 
Logvorgang zu aktualisieren, und zwar nicht so, daß jeder empfangener 
Datensatz ausgegeben wird, sondern so, daß bei jeder 
Bildschirmaktualisierung die letzten 40 (oder wieviele auch immer 
sichtbar sind) ausgegeben werden.

von Hans (Gast)


Lesenswert?

Ich frage mich, wovon man ausgehen soll:

a) Alle protokollierten Daten werden ausgegeben.

b) Es werden (nur) soviele Daten ausgegeben, dass die 
"Scrollgeschwindigkeit" einen bestimmten Wert nicht überschreitet.
Der Wert richtet sich danach, was das menschliche Auge noch erkennen 
kann.

Mein Vorschlag:

Das Steuerelement hat eine bestimmte Anzahl Zeilen (z.B. 80 Zeilen).
Die Logdaten laufen durch einen Ringpuffer, der 80 Einträge hat.
Ein Timer schreibt periodisch den Ringpuffer in das Steuerelement.

=> Wenn die Daten relativ langsam reinkommen, entsteht tatsächlich ein 
Scrolleffekt, wie gehabt.
=> Wenn die Daten zu schnell reinkommen rutschen zwischen zwei 
Aktualisierungen Daten durch den Puffer, was aber egal ist, man kann sie 
sowieso nicht lesen (erkennen).
=> Wenn keine Daten mehr kommen, werden auch keine Daten mehr durch den 
Puffer geschoben, sondern die letzten 80 bleiben dort stehen und werden 
immer wieder in's Steuerelement geschrieben (evtl. double-buffer 
verwenden, wegen dem flimmern, das sonst entsteht)

Sollen im nachhinein Daten angezeigt werden, die nicht im Steuerelement 
stehen, kann man sie über eine (Such-)Maske abrufen.

Kannst Du mal ein Mengengerüst nennen: Wieviele Zeilen/s bzw. MB/s 
sollen denn verarbeitet werden?

von Peter (Gast)


Lesenswert?

So als Vorschlag, aufwendig aber wohl das schnellste:

- Einen Ring- (oder sonstwas) Puffer der die Daten aufnimmt (am besten 
Binär, da kompakter).

- Ein Ausgabefenster welches die Binärdaten interpretiert anzeigen kann.

- Ein dazu passender Scrollbalken um die Anfangszeile zu verschieben

siehe dazu DrawText(...) in der MSDN.

Gruss
Peter

von H. D. (c3po)


Lesenswert?

@Hans:
ausgehen kannst du von a) alle protokollierten Daten + zusätzliche Infos 
die direkt ausgewertet werden.

Ich sehe schon am besten mache ich es so
Das was auf dem Bildschirm erscheinen soll wird in einer Datei 
ausgegeben statt auf dem Screen
Der Screen aktualisiert sich zyklisch und holt sich die letzten x Zeilen 
aus der Datei
wenn man sich dann die Daten (die eigentlich auf dem Screen angezeigt 
werden sollten) ansehen will holt man sich den entsprechenden Ausschnitt 
aus der Datei heraus

==> schreiben eines entsprechenden Anzeige-Controls
+ Scrollbars

das dumme dabei ist nur dass ich dann nicht einfach hergehen kann und 
wie im Richedit machbar einen bereich markieren, kopieren um ihn dann 
woanders einzufügen, zumind. nicht ohne längere umsetzungszeit

bzgl.: der Menge, theoretisch was der Rechner hergibt
Damals waren es etwa max 8 * 115kBit sprich etwa 1MB
aber das Programm hat da keine Restriktion bzgl. der Anzahl der Kanäle
So viele RS232 wie angeschlossen werden können und das Programm öffnet 
soviel wird eben geloggt und gleichzeitig angezeigt...

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.