Une application console qui se substitue à une autre

**Roland Chastain** · 30/10/2018, 18h07

Bonjour ! J'essaie de résoudre le problème suivant.

Soit une application console, Upper.exe, qui renvoie en majuscules tout ce qu'elle reçoit.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
program Upper;
 
uses
  SysUtils;
 
var
  s: string;
 
begin
  while not EOF do
  begin
    ReadLn(s);
 
    if s = 'quit' then
      Break
    else
      WriteLn(UpperCase(s));
  end;
end.

Soit une deuxième application, UpperInterface.exe, qui sera l'application effectivement utilisée par... l'utilisateur, et qui devra se comporter extérieurement comme Upper.exe, après l'avoir lancé.

J'ai un code basé sur l'API Windows qui fait presque cela, sauf qu'il reste bloqué. Si je lance UpperInterface.exe et que je saisis quelque chose dans la console. Rien ne se passe. C'est lorsque j'appuie sur Ctrl+Z puis entrée que je vois apparaître la "réponse" de Upper.exe.

Qu'est-ce que je dois faire ? Mettre le ReadLn dans un thread aussi ? Utiliser WaitForSingleObject, PeekNamedPipe, PeekConsoleInput... Je me perds dans tout ça.

J'espère que j'ai été clair. ~~Ci-joint le code des deux programmes.~~ Voir plus loin un exemple qui fonctionne.

**Roland Chastain** · 30/10/2018, 21h09

En fait c'est toujours le même problème que celui abordé dans cette vieille discussion. J'avais trouvé un programme en C qui faisait ce que je voulais. Je l'ai traduit en Pascal mais la version Pascal n'a jamais fonctionné.

Je vais peut-être le faire en C, tout compte fait, mon programme.

**BeanzMaster** · 31/10/2018, 11h41

Salut Roland

Si j'ai bien compris tu as un programme "UpperInterface.exe" lancé par ton programme de jeux d'echec (disons "Echec.exe") . "UpperInterface.exe" lance et doit récupérer les infos retournés par "Upper" et les renvoyés lui même dans "Echec.Exe" c'est bien ça ?

As tu essayé de passer par TProcess ? cf https://www.developpez.net/forums/d1.../#post10167133

A+

[EDIT] sinon peut-être avec les composants IPC https://www.developpez.net/forums/d1.../#post10238316

**Roland Chastain** · 31/10/2018, 12h58

Bonjour Jérôme ! Oui tu as très bien compris mais pour ne pas compliquer les choses on peut faire abstraction d'Echec.exe. Là dans ce cas disons que c'est un simple utilisateur qui ouvre UpperInterface.exe, qui tape "bla" et UpperInterface.exe doit lui répondre "BLA".

Merci pour les liens. Je vais les regarder.

D'un autre côté comme j'ai un programme en C qui le fait, je me suis remis à étudier ce programme.

Le problème sur lequel je bute, c'est d'écrire dans la console tout en laissant la possibilité à l'utilisateur d'entrer quelque chose. Enfin, c'est quelque chose comme ça.

**BeanzMaster** · 31/10/2018, 13h37

Voila j'ai fais un test vite fait, je pense que c'est plus ou moins ce que tu recherches

ShareConsole.zip

PS : pour UpperTool il faut le compiler sans débogage

[EDIT] voici une variante fonctionnelle de Client :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
program Client;
 
{$mode objfpc}{$H+}
 
{$IFDEF WINDOWS}
  {$APPTYPE CONSOLE} // Définition du type d'application
  {$CODEPAGE UTF-8}  // A rajouter sous Windows pour forcer le mode UTF-8 pour les chaînes de caractères en mode console
{$ENDIF}
 
uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  // Classes,
  SysUtils,  Process, Processutils //FileUtil,LConvEncoding,LazUTF8
  { you can add units after this };
 
var
  UpperToolOutput : String;
 
procedure ProcessOutput(Sender:TProcessEx; output:string);
begin
  UpperToolOutput := Output; //ConsoleToUtf8(output);
end;
 
procedure ProcessError(Sender: TProcessEx; IsException: boolean);
begin
  if IsException then
    UpperToolOutput := 'Erreur ! ' + Sender.ExceptionInfo
  else UpperToolOutput := 'Erreur inconnue ! ';
end;
 
var
  UserInput : String;
  cmdProcess : TProcessEx;
begin
  WriteLn('Entrez quelque chose :');
  ReadLn(UserInput);
  try
    cmdProcess := TProcessEx.Create(nil);
    cmdProcess.ShowWindow := swoHIDE;
    cmdProcess.Executable := 'UpperTool' ;
    cmdProcess.Parameters.Add(UserInput);
    cmdProcess.OnError := @ProcessError;
    cmdProcess.OnOutput := @ProcessOutput;
    cmdProcess.Execute();
   // if ExecuteCommand('UpperTool '+UserInput, UpperToolOutput,false) <> 0 then UpperToolOutput := 'Erreur !';
  finally
     FreeAndNil(cmdProcess);
  end;
 
  Write('Réponse : '); writeln(UpperToolOutput);
  Readln;
 
 
end.

**Roland Chastain** · 31/10/2018, 14h17

Merci pour ton code Jérôme. Cette unité ProcessUtils a l'air intéressante.

Mais ton exemple ne fait pas la même chose que le mien. Tu passes un paramètre à l'outil au moment où tu l'exécutes. Ça ne convient pas, parce que moi j'ai besoin de lui envoyer de nouvelles commandes à tout moment.

**BeanzMaster** · 31/10/2018, 14h36

Je ne comprend pas, avec mon exemple, depuis le "Client" tu peux lui demander d'exécuter n'importes quelles commandes quand tu le souhaites. Il te suffit d'ajuster le retour de "UpperTools" en fonction des paramètres que tu lui passes.

C'est toi qui contrôles les arguments. "Tools" ne reste pas en mémoire c'est le "Client". Du coup j'ai du mal à cerner le problème maintenant.

Exemple :
Tools.exe cmdUpperCase ChaineEnMinuscule
Tools.exe cmdLowerCase ChaineEnMajuscule

Peut-être avec un système d'échange, avec un ou deux fichiers de données commun physique sur le disque (1 pour les entrées et le 2eme pour la sortie). Les deux applications devront être en mémoire. Mais dans ce cas il faudra faire une vérification de la date de modifications ou un truc dans le genre.

Si il faut que le client et l'outils restent en mémoire le protocol d'échange ICP est la meilleur solution à mon avis.

EDIT :

Qu'entends tu par

j'ai besoin de lui envoyer de nouvelles commandes à tout moment.

tu veut lui passer ces commandes de quelle manière, exactement ?

**Roland Chastain** · 31/10/2018, 15h34

Merci Jérôme pour ta contribution. Le client, c'est un programme déjà existant, qui n'est pas forcément mon programme. Donc pas de modification possible de ce côté-là. C'est un protocole utilisé par tous les logiciels d'échecs.

Or ce programme se comporte comme un utilisateur qui lancerait le moteur (Upper.exe dans mon exemple) depuis l'invite de commandes et entrerait successivement plusieurs commandes, au clavier, dans une espèce de dialogue dans le temps avec le moteur.

Du reste la solution revient à celle que tu proposes, sauf que les modalités sont imposées.

**BeanzMaster** · 31/10/2018, 18h41

Ok donc en fait ce que tu cherches c'est récupérer les réponses fournis par "upper" dans la console. Sous windows, effectivement il existe une api pour faire ce genre de choses.
Il y avait eu si je me rappel bien une discussion, il y déja pas mal de temps dans le forum Delphi. Donc pas sure que la réponse soit encore présente.

Sous windows du moins, il faudrait que tu récupères le handle de la fenêtre de la console rattachée à son processus en l'occurence "UpperInterface.exe" qui doit lui même créer un nouveau sous-process pour upper et récupérer la sortie console depuis ce processus. Ou sinon a voir si upper tourne dans son propre "processus" et là récupérer le handle de "upper".

Regardes de ce coté https://docs.microsoft.com/en-us/win...tconsolewindow et les autres fonctions readconsoleoutput, et consolectrlhandler. Pour linux par contre pas d'idées mis à part l'utilisation de la commande "cat" ou trouver son processus PID.

voila une explication sommaire de ce que j'ai trouvé http://coding.bug.free.fr/win/console.htm#redirect2 pour windows

Rediriger les flux d'Entrée/Sortie d'une autre console
Rediriger le flux d'une autre console (donc de celle d'un autre processus) nécessite de recourir à un pipe.
Si vous redirigez l'ensemble des flux d'une console a déjà été créée, cette dernière restera visible, bien qu'elle perde toute utilité.
Si vous voulez faire disparraître la console d'un programme CUI et interragir avec lui en regirigeant ses flux (typiquement pour piloter un programme CUI depuis un programme GUI), c'est à votre programme de créer le processus CUI en lui faisant hériter vos propres flux ce qui ne provoquera pas la création d'une console.

Je viens de tomber la dessus en .Net http://gilles.tourreau.fr/dotnet_fra...processus.html

**Roland Chastain** · 01/11/2018, 13h17

Merci Jérôme pour ta contribution. J'ai réussi à faire quelque chose qui fonctionne, en partant d'un exemple que j'avais trouvé sur le forum Lazarus anglophone. Je doute que ça puisse fonctionner correctement dans des conditions réelles (c'est un peu lent) mais enfin c'est un point de départ.

**Roland Chastain** · 01/11/2018, 16h33

Une autre version qui fonctionne, basée sur l'unité Windows. La version 2 est basée sur l'unité Process.

Je pense qu'il doit y avoir besoin d'un thread quelque part, mais je n'ai pas encore trouvé la bonne formule. Est-ce qu'on lance un thread pour écouter les messages de upper.exe, ou est-ce qu'on lance un thread pour lire l'entrée standard de upperintf.exe ?

J'ai besoin que l'utilisateur puisse saisir à tout moment quelque chose dans la console de upperintf.exe.

Une application console qui se substitue à une autre [Free Pascal]

Free Pascal

Discussions similaires

Partager

Partager