M
(D)Evil schrieb:
Also in C++ haben Streams, die von std::ios abgeleitet sind, einen Buffer(std::basic_streambuf).
Wenn du nun einen eigenen streambuf von std::streambuf ableitest, und setzt dann den Buffer:
my_streambuf buffer;
std::cout.rdbuf(&buffer);
std::clog.rdbuf(&buffer);
std::cerr.rdbuf(&buffer);
ein Beispiel, wie du von std::streambuf ableitest, findest du als "Weiche" hier im Forum.
Funktioniert das?? In meinem Fall jedenfalls nicht so wie gewünscht!
Von einem Konsolenprogramm werden normalerweise mehrere und verschiedene Aufrufe von cout getätigt. Nach einem flush() landet der Inhalt von Streampuffer auf dem Bildschirm. Danach ist der Streampuffer wieder leer, der ehemalige Inhalt aber bleibt auf dem Screen erhalten.
Das einfache "Umbiegen" des Streampuffers auf einen eigenen oder den einer CView-Klasse bringt nicht das gewünschte Ergebnis. Wie schon erwähnt, wird nach einem flush() der Puffer geleert. Nach einem Neuaufbau des Bildschirms wäre dann auch der alte Inhalt weg.
Was ich brauche ist ein Stream, der den Inhalt seines Puffers an den Inhalt der CView hintanhängt. Nun habe ich keinen direkten Zugriff auf den Puffer/Speicher von CView bzw. CRichEditView und kann nur über Memberfunktions Inhalte einfügen.
Bei dem Versuch, meiner Streamklasse Zugriff auf die geschützen bzw. privaten Funktionen von CRichEditView zu ermöglichen habe ich mich verheddert. Ein "Schlupfloch" konnte ich nicht finden.
Den erwähnten Zirkelschluss konnte ich inzwischen brechen. Ich muss nur meinem Stream nicht CView mitgeben sondern die Tochterklasse, die den Inhalt verwaltet, nämlich CRichEditCtrl.
Damit muss CView meinen Stream kennen und mein Stream eben nicht CView sondern CRichEditCtrl. Damit komm ich hin.
Die Abhängigkeiten der MFC sind derart verworren und vielschichtig, dass ich es als "Hobbyprogrammierer" nicht hinbekommen hatte, alle Abhängigkeiten zufrieden zu stellen. Und dann fängt man an zu probieren und zu basteln und verschlimmbessert alles. Na ja, jetzt tutet es.
MQ
