Moin,

ich möchte einen Adapter zur Konsole schreiben, der an sich die gleichen Funktionen anbietet, wie die Konsole selber, allerdings anders umsetzt.
Die Idee dahinter ist, dass ich diesen Adapter um weitere Funktionen erweitern kann, z.B. eine implizite Validierung der Eingaben, dass dem User gar nicht erst die Möglichkeit bleibt, falsche Zeichen einzugeben.

Mein bisheriger Ansatz war der, dass die ReadLine-Methode durch eine völlig andere Arbeitsweise ersetzt wird, nämlich eine Schleife, die so lange ReadKey() ausführt, bis dieser eingelesene Key die Enter-Taste ist. Hier wäre dann z.B. möglich, zu prüfen, ob die Eingabe validiert werden kann, weil die Schleife sonst einfach nicht unterbrochen wird.

Probleme gab es bei so Funktionen, wie das Verrücken des Cursers, Einfügen und Löschen, nicht editierbarer Text vor der Eingabe, Auswählen der vorherigen Eingaben durch die Up-/Down-Pfeile, etc.


Den Großteil habe ich gelöst und der Adapter funktioniert an sich auch relativ gut, allerdings ist das mittlerweile ziemlich groß und umständlich geworden, weshalb ich ganz gerne eine andere einfacherer Herangehensweise finden würde.


Im Moment schaue ich, ob ich eine Klasse von TextReader ableiten kann um da etwas einzubauen, aber ob das funktioniert, bezweifle ich.


Hat da vielleicht jemand eine Idee, wie so ein möglichst flexibler Konsolen-Adapter arbeiten könnte?


Gruß

Vorab: Ich entwickle mit Pascal (Delphi), nicht Cxxx,
deshalb wei0 ich wohl auch nicht so richtig was ein »Adapter« ist - bei mir ist das eine function bzw. eine Folge von Functionen.

Die zentrale function bekommt als normale Parameter
- die Werte des Lesefeldes, X,Y,Länge,Farbe(n) und
- einen String (leer oder Vorgabe) übergeben
und liefert
- den gelesenen String und
- den Beendigungs- bzw. Abbruch-Char
zurück.

Zusätzlich werden drei charMengen übergeben,
- eine Menge für zulässige Zeichen (aus der Menge der druckbaren Zeichen),
- eine Menge für Bewegungs-Steuerzeichen zur Bewegung innerhalb des Lesefeldes und
- eine Abbruch/Ende-Menge für das Beenden des Lesens im Lesefeld (nur CR als Ende ist etwas wenig, bei Dateneingaben in Listen muß auch die Bewegung zu einer anderen Zeile oder Spalte eine Ende-Bedingung sein sowie ein Abbruch (mit/ohne Storno)).

Gelesen wird in einer Schleife immer nur ein Zeichen ohne Echo,
- die Menge der zulässigen Zeichen ist die erste Vorabprüfung der Eingaben und nur zulässige Zeichen werden auch per Echo angezeigt und verschieben den Cursor,
- die Menge für Bewegungs-Steuerzeichen verschiebt nur den Cursor,
- ein Zeichen aus der Abbruch/Ende-Menge beendet die Eingabe und liefert den gelesenen String sowie das Ende-Zeichen zurück.

Nach Ende erfolgt evtl. eine zweite anwenungsspezifische Gültigkeits-Prüfung.

Aufgerufen wird die zentrale Lese-Function von »typisierten« Lese-Functionen, die auch die genannten Mengen bilden/setzen und typbasierte Vorab-Gültigkeitsprüfungen übernehmen. Parallel dazu gibt es dieselben »typisierungen« auch als reine Schreib-Prodeduren mit derselben Parameter-Liste (dto. auch als Druckaufruf). Die »typisierten« Lese-Functionen schreiben am Ende (nach evtl. typbasierte Vorab-Gültigkeitsprüfung) das Ergebnis mit der entspr. reine Schreib-Prodedur noch einmal als Echo in das Lesefeld.

Ich weiß nicht, was Du als »ziemlich groß und umständlich geworden« meinst - nur alles was allgemeingültig für alle Anwendungen fehlerfrei funktionieren soll, wird zwangläufig etwas größer, schon allein durch internes Abfangen/Vermeiden von Fehlern durch Bereichsüberschreitungen und unzulässige Vorgaben, damit man anschließend beim Anwenden in einer Anwendung umso weniger Zeilen hat, im Idealfall nur eine Zeile.

Ich bin mit diesem meinem System, welches direkt fast unverändert aus PASCAL-DOS-Anwendungen beim Umschreiben auf Windows-Konsole übernommen wurde, glänzend gefahren - incl. DOS-Zeiten nun fast 30 Jahre. In der Zeit sind ständig Ergänzungen/Erweiterungn/Anpassungen hinzu gekommen.

Ob der Name "Adapter" so ganz richtig ist, weiß ich nicht, aber ich meine damit eine Klasse, die die gleichen Funktionen der Konsole bereit stellt, die auch das gleiche Ergebnis haben, allerdings vorher noch überprüfen.

Umständlich wurde die Klasse, weil ich versucht habe, alle Funktionen der Konsole nachzubilden. So habe ich auch eingebaut, dass mit den Hoch-/Runter-Pfeilen vorherige Eingaben ausgewählt werden können, da bin ich dann auch hängen geblieben, weil das eine Exception geworfen hat, die ich mir beim besten Willen nicht erklären konnte.


Mittlerweile probiere ich es so, dass ich einen TextReader schreibe, der selber den TextReader der Konsole intern nutzt. Und dann gebe ich der Konsole ein Objekt dieses neuen TextReaders, sodass sie meinen Reader nutzt, der zwar nur durchleitet, aber zusätzlich noch validiert.
Da kann ich dann erst einmal einen Reader bauen, der einzig und allein dafür da ist, die minimalen Konsolen-Funktionen mit dieser anderen Arbeitsweise nachzubilden. Also nur Texteingabe, Löschen, Bestätigen.
Davon leite ich dann weitere Klassen ab, die das ganze dann entsprechend erweitern und dann ist das ganze auch nicht mehr so überfüllt und unübersichtlich.



Ob das so funktioniert, kann ich nicht sagen, aber ich kann es ja versuchen

Palladin007 hat folgendes geschrieben :

So habe ich auch eingebaut, dass mit den Hoch-/Runter-Pfeilen vorherige Eingaben ausgewählt werden können, da bin ich dann auch hängen geblieben, weil das eine Exception geworfen hat, die ich mir beim besten Willen nicht erklären konnte.

So etwas in die Klasse selbst einzubauen, halte ich persönlich für arg überzogen, da kaum allgemeingültig darstellbar. Woher weißt Du jetzt, was Du übermorgen mit den Steuertasten meinst? Das würde ich immer nach außen verlagern.

Aber ich persönlich würde die Consolen-Classen eh nicht anfassen und meine eigenen Functionen nach außen verlagern oder max. als Ergänzung schreiben, schon um Fehler besser lokalisieren und beseitigen zu können.

Ich persönlich wende in Consolen-Programmen eh kaum OOP an, schon aus dem Grund, weil ich Consolen-Anwendungen nur dort verwende, wo ich alte DOS-Anwendungen ca. 1:1 auf Windows-Console umschreibe - und das auch hauptsächlich nur wg. der langen Dateinamen/Pfade und Druckeransteuerungen (Stichwort USB).