![]() |
Das b(l)ockige ReadLn einer Konsolenanwendung - Workaround?
Moin !
Zum Testen nutze ich dann und wann gerne Konsolenanwendungen. Die sind schnell geschrieben und bei einigen Dingen ganz praktisch. Jüngst habe ich mir eine Konsolenanwendung geschrieben mit einem TIdTCPClient. Im Grund soll die Anwendung Kommandos an den Server senden und das Feedback des Servers ausgeben. Das Auslesen des Server Feedbacks geschieht in einem eigenen Thread und funktioniert auch ganz gut. In der Anwendung gibt es dann diese Stelle hier:
Delphi-Quellcode:
Ich lese was ein und schreibe es weg zum Server. Auch das funktioniert. ABER ... Das Readln blockt die Ausgabe in die Console. Selbst wenn der Thread Daten zum Auslesen bekommt, so werden diese nicht dargestellt. Letztlich macht der Thread ein WriteLn(Msg);.
while Input <> 'q' do begin
Write('--> '); Readln(Input); Client.IOHandler.WriteLn(Input); end; Gibt es einen Weg um dieses ReadLn Dilemma zu umgehen? |
Re: Das b(l)ockige ReadLn einer Konsolenanwendung - Workarou
Ich vermute stark, daß Du bei einer Console Pech hast. Solange kein CR eingelesen wurde, gehört die Console exklusiv dem Readln.
Gruß K-H |
Re: Das b(l)ockige ReadLn einer Konsolenanwendung - Workarou
Moin !
Ja sowas hab ich schon vermutet. Mist ... Ob man das mit Read anstatt Readln in den Griff bekommen könnte? Und das CR selber überwachen ? |
Re: Das b(l)ockige ReadLn einer Konsolenanwendung - Workarou
Read, wartet auch auf die Eingabe.
Du kannst also "nur" den Tastaturstatus abfragen. |
Re: Das b(l)ockige ReadLn einer Konsolenanwendung - Workarou
muss es denn überhaupt ReadLn() sein? Du kannst doch auch mit ein paar Leerzeilen (WriteLn()) und ein paar Sleeps das ganze auch ohne machen, oder willst du explizit darauf warten, dass der User/du selbst was eingibt?
Bernhard |
Re: Das b(l)ockige ReadLn einer Konsolenanwendung - Workarou
Moin Bernhard,
ich habe es jetzt hinbekommen. :) Kann gleich auch mal meinen Code posten - der ist aber aufgrund der Tests noch sehr konfus :D Anyway .. Ich werte jetzt in einem Thread den InputBuffer und lese den ggf. mit ReadBytes. Das verhindert schon mal eine Blockade beim Lesen vom socket. In der Consolenanwendung selber nurtze ich Read um Zeichen zu lesen und werte das CR & LF aus. Das Read blockt kann ich nicht bestätigen. Wenn ich nämlich im Thread zyklisch einfach was auf die Console schreibe, dann wird es angezeigt obwohl ich ein Read aktiv habe was auf ein Zeichen wartet. Bei enter wird das Commando dann dem TIdTCPClient gegeben zum Verschicken - "gesichert" über einen TMutex. Das klappt bis jetzt wunderbar. Ich kann eingaben machen und parallel dazu bekomme ich direkt Feedback auf der Console. :) |
Re: Das b(l)ockige ReadLn einer Konsolenanwendung - Workarou
Nur aus Neugier: Für eine Testanwendung wäre ein VCL-Projekt wirklich nicht einfacher gewesen? Klar, hast du jetzt wieder was neues gelernt, aber...effizient ist das nicht unbedingt, oder? ;)
Sherlock |
Re: Das b(l)ockige ReadLn einer Konsolenanwendung - Workarou
Moin !
Zitat:
Ich ich mag nunmal Consolenanwendungen :P Und es hat mich gereizt das hinzubekommen. :mrgreen: |
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:55 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz