Handle von Konsolen-App?

[charly52]

Zitat von himitsu:

Aus den ersten Suchergebnissen...
https://www.delphipraxis.net/117567-...ung-nicht.html
Zeigt zumindestens schonmal ansatzweise, wie das aussieht
* Pipes erstellen
* * mindestens hStdInput, wo du deine Befehle rein schreiben kannst
* * und eventuell auch noch hStdOutput, wo die Antwort zurück kommt
* dann damit den Prozess starten
* auf dessen Ende warten
* und währenddessen die Ein-/Ausgaben behandeln, also in StdIn reinschreiben und aus StdOut lesen (ja, andersrum, da aus Sicht des gestarteten Programms)

hi himitsu,

danke, das hat schon richtig geholfen.
Kann jetzt meine KonsolenApp starten.
Habe dann im Code von little_budda an der Stelle

//jetzt mit ReadFile/WriteFile kommunizieren

folgendes eingeführt:

Delphi-Quellcode:

  
var
    chBuf   : Array[1..2] of Char;
    written : longWord;

begin 
  .........
//jetzt mit ReadFile/WriteFile kommunizieren
    while true do
      begin
        chbuf[1]:= '3';
        chbuf[2]:= #13;

        bSuccess:= WriteFile(WriteInput{g_hChildStd_IN_Wr}, chBuf, 2{dwRead}, Written{&dwWritten}, nil);

        if (NOT bSuccess) then
        begin
          err:= GetLastError;
          break;
        end;
      end;

Und jetzt was zum Verständnis.
Wenn ich in der STARTUPINFO Struktur einen "Input-Handle" für die KonsolenApp erzeuge
  CreatePipe(StartStruct.hStdInput, WriteInput, @SecAttr, 0); //die Handles erzeugen sollte ich mit WriteFile doch direkt da reinschreiben könen? Oder nicht?

Oder muss ich in der KonsolenApp auch noch explizit aus dem neuen Handle lesen?
Ich dachte eigentlich, das beim Starten der KonsolenApp deren StdInput schon umgebogen wird?????

Ihr seht, mir fehlt da ganz Grundsätzliches

Danke für weitere Hilfe


Charly

[himitsu]

Das STARTUPINFO gibt der Anwendung ein optionales Handle. (ist das leer, dann werden die Standrad-Handles des Systems verwendet)

Du schreibst in WriteFile(PipeWrite, ... und in der anderen Anwendung kommt es dann bei GetStdHandle(STD_INPUT_HANDLE) an, bzw. bei den Delphi-APIs, welche das nutzen, wie z.B. ReadLn (ohne den File-Parameter).

Andersum genauso, wenn die andere Anwendung auf STD_OUTPUT_HANDLE schreibt, bzw. mit WriteLn,
dann kommt es bei dir im PipeRead (STARTUPINFO.hStdOutput)

[charly52]

Das heist also, daß ich in meiner Konsolenapp _nichts_ tun muß?
Das readln liest ja bereits aus StandardIn.

Bei mir kommt in der KonsolenApp nämlich nichts an wenn ich z.B 2 Chars ('3' und #13) schicke.
ABer in der Variablen "written" steht ne 2 und bSucess ist auch True.
Und eigentlich sollte doch dann meine App die '3' mit nem CR dahinter genau wie ein Kommando wie von der Tastatur
hier ne 3 und Enter behandeln?
Das tut sie nicht!!!!

Charly

[himitsu]

Wie schickst du diese Chars?

das Encoding ist schon wichtig.

[Delphi.Narium]

ReadLn ließt bis zum nächsten Zeilenumbruch und der ist unter Windows #13#10. Es gibt dazu auch die Konstante sLineBreak, mit der ist man dann plattformunabhängig, da sie automatisch den für die Zielplattform richtigen Wert enthält.

[himitsu]

ReadLn ist es egal, es kommt allen Kombinationen zurecht, also CR, CR+LF oder LF (so wie die TStringList)

[charly52]

Hallo himitsu, Delphi.Narium

erstmal VIELEN Dank für eure Hilfe, ich habe da wirklich nur im Nebel gestochert.
Jetzt gehts. Aber ihr habt beide nur teilweise recht.
Meine Konsole/werauch ímmer kann wohl nur AnsiChar

und somit sende ich:

Delphi-Quellcode:

//  chBuf   : Array[1..3] of AnsiChar = ('3',#13,#10);   //geht
//  chBuf   : Array[1..3] of AnsiChar = ('3',#10);       //geht
    chBuf   : Array[1..2] of byte = (51,10);             //geht

begin

    bSuccess:= WriteFile(WriteInput{g_hChildStd_IN_Wr}, chBuf, 2 | 3 (je nach definition oben), Written, nil);

Zitat von himitsu:

ReadLn ist es egal, es kommt allen Kombinationen zurecht, also CR, CR+LF oder LF (so wie die TStringList)

Nur CR geht NICHT

Zitat von Delphi.Narium:

ReadLn ließt bis zum nächsten Zeilenumbruch und der ist unter Windows #13#10. Es gibt dazu auch die Konstante sLineBreak, mit der ist man dann plattformunabhängig, da sie automatisch den für die Zielplattform richtigen Wert enthält.

Es geht auch NUR #10
Aber sLineBreak geht wiederum nicht, da es WideString ist.


Danke Charly

[himitsu]

Ja, Delphi-Consolen können nur ANSI, bzw. OEM. (was sich jeweils umschalten ließe)
Aber wenn man nicht die uralten Delphi-Funktionen verwendet, dann wäre auch alles Andere Möglich.

Delphi-Quellcode:

function _WriteWString(var t: TTextRec; const s: WideString; width: Longint): Pointer;
var
  i: Integer;
begin
  i := Length(s);
  _WriteSpaces(t, width - i);
  Result := _WriteLString(t, AnsiString(s), 0);
end;

procedure _ReadUString(var t: TTextRec; var s: UnicodeString);
var
  Temp: AnsiString;
begin
  // !!! FIXME
  _ReadLString(t, Temp, DefaultSystemCodePage);
  s := UnicodeString(Temp);
end;

Das sLineBreak hat per se in seiner Deklaration keinen Typen.
Es müsste sich demnach jeweils an den Zieltyp anpassen (der Compiler dürfte es bereits gecastet übergeben). Und selbst wenn nicht, dann würde es bei Verwendung einfach implizit gecastet.

Zitat:

Nur CR geht NICHT

Laut Code sollte es aber gehn.

Delphi-Quellcode:

procedure _ReadLn(var t: TTextRec);
{$IF not defined(CPU386)}
var
  c: Word;
begin
  while True do
  begin
    c := _ReadCharEx(t);
    if (c and $00ff) = cLF then break; // accept LF as end of line
    if (c and $ff00) shr 8 = cEOF then break;
>>> if (c and $00ff) = cCR then
    begin
      c := _ReadCharEx(t);
>>>>> if (c and $00ff) = cLF then break; // accept CR+LF as end of line
      if (c and $ff00) shr 8 = cEOF then break; // accept CR+EOF as end of line
      Dec(t.BufPos);
      // else CR+ anything else is not a line break.
    end;
  end;
end;