Discussion :

[naute]

Bonjour .

Dans mon application, je lance des processus avec TProcessEX. Je n'ai aucun moyen de savoir à l'avance si mon processus va aboutir. Or, s'il n'aboutit pas, mon appli reste bloquée et je n'ai d'autre solution que de la fermer et de la relancer. Ce n'est pas dramatique mais ça ne fait pas très abouti . Y a-t-il un moyen plus élégant de traiter le problème ?

Pour info :

• Lazarus 2.0.10 / FPC 3.2 sous Debian 9 ;
• le processus, quand il aboutit, retourne une chaîne de caractère, via la liaison USB, que je récupère avec TProcessExOutPut.

Merci pour vos avis.

Amicalement,
naute

[Roland Chastain]

Bonjour ! Peut-être lancer le processus dans un fil d'exécution séparé ? Il y a un exemple ici (que je n'ai pas essayé) :
https://www.sigmdel.ca/michel/progra...thread_en.html

P.-S. Sur cette page il y a un projet complet :
https://sigmdel.ca/michel/downloads_fr.html

[naute]

Merci Roland . J'avais bien envisagé d'utiliser un Thread, mais c'est un domaine que je ne connais pas. Je regarde...

À bientôt.

[naute]

Bonjour Roland .

Bien que n'ayant pas encore totalement compris le mécanisme des threads, j'ai réussi à adapter à mon cas le code de l'exemple dont tu m'as fourni le lien. Ça semble fonctionner correctement pour le moment, et il n'y a pas de raison pour que ça change .

encore !

Amicalement,
Hervé

[Roland Chastain]

Bonjour Hervé ! Pas de quoi. Content de savoir que tu as pu résoudre ton problème.

[BeanzMaster]

Salut Hervé

As tu essayé avec l'unité BZProcessEx car le processus s"exécute dans un thread que l'on avait discuté dans ce fil de discussion ?

A+

Jérôme

[naute]

Bonjour Jérôme .

As tu essayé avec l'unité BZProcessEx car le processus s"exécute dans un thread que l'on avait discuté dans ce fil de discussion ?

Je suis allé voir, bien sûr, et je te remercie à nouveau pour l'aide que tu m'as apportée sur le fil dont tu parles. Le problème est que ton composant n'est pas directement utilisable dans mon cas. Notamment, sauf erreur de ma part, il n'accepte pas les lignes de commande comprenant plusieurs paramètres séparés par un espace. Par exemple, la ligne :

Code pascal :

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

Process.Parameters.add('param1 param2 param3)')

ne fonctionne pas.
Il faut générer une ligne de type Process.Parameters.add() par paramètre, comme ceci :

Code pascal :

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

1
2
3
4
 
Process.Parameters.add('param1');
Process.Parameters.add('param2');
Process.Parameters.add('param3');

J'ai écrit la petite routine suivante pour mon appli :

Code pascal :

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
 
procedure TEspThread.ParseCommandLine(Process: TProcessEX; CommandLine: string);
var
  Param: string;
begin
  Param := '';
  while not (CommandLine = '') do
  begin
    while not ((Copy(CommandLine, 0, 1) = ' ') or (CommandLine = '')) do
    begin
      Param := Param + Copy(CommandLine, 0, 1);
      Delete(CommandLine, 1, 1);
    end;
    Process.Parameters.Add(Param);
    Param := '';
    if (CommandLine <> '') then Delete(CommandLine, 1, 1);
  end;
end;

mais je ne sais pas comment l'intégrer dans le code de ton composant qui est un peu compliqué pour moi (on ne joue pas dans la même cour ). Ce qui fait que je n'ai pas pu tester.

De plus, dans ton appli test "NewProcessEX" (Test Process), je ne comprends pas la distinction que tu fais entre "Paramètres" et "Commande" (les deux TEdit) d'une part, et entre les commandes "Exécuter" et "Envoyer la commande" d'autre part.

Amicalement,
Hervé

[BeanzMaster]

Salut Hervé

Il faut générer une ligne de type Process.Parameters.add() par paramètre, comme ceci :

Ce comportement est tout à fait normal, c'est la même chose avec le natif TProcess. "Params" est de type "TStrings".

Pour passer tes paramètres en une seule ligne il faut faire :

Code :

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

1
2
3
 FProcessEx.Params.Clear;
 FProcessEx.Params.Delimiter := ' ';
 FProcessEx.Params.DelimitedText := 'param1 param2 param3'; //edtParams.Text;

J'ai écrit la petite routine suivante pour mon appli :

Idée à méditer dès que j'aurais plus de temps libre. Je suis en pleine formation de reconversion en ce moment.

De plus, dans ton appli test "NewProcessEX" (Test Process), je ne comprends pas la distinction que tu fais entre "Paramètres" et "Commande" (les deux TEdit) d'une part, et entre les commandes "Exécuter" et "Envoyer la commande" d'autre part.

"Commande" c'est l'exécutable. "Python" par exemple
"Paramètres" les arguments à passer à ton exécutable. exemple "-i"
"Exécuter" va lancer le processus. Avec l'exemple ci-dessus, ce sera "python -i"
"Envoyer la commande" : Sert à "écrire dans la console", quand le processus attend que l'utilisateur interagisse avec lui. Il te demande ton prénom par exemple. Tu pourras lui envoyer "Hervé" par le biais de cette méthode (tu peux essayer avec la demo "NewProcessEX" en lançant l’exécutable "testinput" (qui se trouve dans le même dossier)

Par rapport à ta problématique, toujours dans la demo "NewProcessEX" essayes "python" comme exécutable et en paramètre "-i test2.py". Tu verras rien ne passe et le processus semble figé. Tu peux arrêter celui-ci simplement en cliquant sur le bouton "Arrêter le processus".

Petite question c'est quelle application que tu lances dans ton projet ?

Voila j'espère que j'ai pu t'éclairer un peu. N'hésites pas au besoin.

A+

Jérôme

[naute]

Bonjour Jérôme .

Avant tout, mes plus plates excuses . La version de NewProcessEx que j'ai utilisée pour mes tests n'était pas la bonne. Ta dernière version fonctionne parfaitement. Donc pour moi et pour toi.

Ce comportement est tout à fait normal, c'est la même chose avec le natif TProcess. "Params" est de type "TStrings".
Pour passer tes paramètres en une seule ligne il faut faire :

Code pascal :

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

1
2
3
4
 
FProcessEx.Params.Clear;
FProcessEx.Params.Delimiter := ' ';
FProcessEx.Params.DelimitedText := 'param1 param2 param3'; //edtParams.Text;

C'est ce que tu fais dans ta dernière version mais pas dans celle que j'ai utilisée, d'où mon erreur .
Du coup, ma petite routine ne sert à rien puisque l'équivalent est déjà implémenté dans TProcessEX, ce que je n'avais pas vu, et donc :

Idée à méditer dès que j'aurais plus de temps libre. Je suis en pleine formation de reconversion en ce moment.

devient inutile. Le travail est déjà fait .

Par contre, je ne comprends pas :

"Commande" c'est l'exécutable. "Python" par exemple
"Paramètres" les arguments à passer à ton exécutable. exemple "-i"
"Exécuter" va lancer le processus. Avec l'exemple ci-dessus, ce sera "python -i"
"Envoyer la commande" : Sert à "écrire dans la console"...

Petite question c'est quelle application que tu lances dans ton projet ?

J'écris des petits programmes pour des microcontrôleurs de la famille des ESP8266. J'utilise soit le C avec l'EDI Arduino, soit le Python. Dans les deux cas, la liaison entre le PC de développement et le microcontrôleur se fait via une liaison série USB.

Pour Python, il faut d'une part que MicroPython, une version de l’interpréteur Python adaptée aux microcontrôleurs, soit installée sur le microcontrôleur, ce qui se fait avec l'outil esptool.py et d'autre part accéder au système de fichier du microcontrôleur, créé par esptool.py, pour y gérer les scripts. Pour cette partie, j'utilise un utilitaire en ligne de commande, ampy.py, qui me fourni les routines de transfert de fichiers entre le microcontrôleur et le PC, de création et de suppression de répertoires, d'affichage console du système de fichier du microcontrôleur etc.

Par exemple, la ligne de commande suivante :

Code bash :

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

1
2
 
ampy -p /dev/ttyUSB0 ls -l -r

me retournera, dans la console, le système de fichiers présent sur l'ESP8266 connecté au port USB0, avec la taille des fichiers et l'arborescence.

À la fois pour des raisons pratiques et pour le plaisir, j'ai écrit une interface graphique pour ampy, et elle fonctionne correctement. Mais j'avais un problème que je n'arrivais pas à régler : quand j’envoie une commande ampy à un microcontrôleur dans lequel MicroPython n'est pas installé, ampy garde la main. En mode console, un <Ctrl C> tue la tâche et la console reprend la main, mais avec l'interface graphique, le processus reste bloqué et il n'y a plus qu'à fermer le programme et le redémarrer, ce qui n'est pas dramatique, mais pas très élégant non plus.

D'où ce fil pour trouver une solution, et qui, en l'occurrence, m'en a fourni deux : celle de Roland et la tienne .

Donc, merci à tous les deux .

Amicalement,
Hervé

EDIT : ça y est, j'ai pigé. Commande représente la ligne de code que Exécutable doit exécuter.

[BeanzMaster]

Yop, pour le coup, je corrige

"Executable" c'est l'exécutable. "Python" par exemple
"Paramètres" les arguments à passer à ton exécutable. exemple "-i"
"Commande" : Sert à "écrire dans la console"... (ou envoyer une touche clavier cf methode SendKey)
par exemple :
- sous Windows tu lances : "cmd" qui est l'exécutable et tu peux lui envoyer un "dir" via commande
- sous Linux tu lances : "bsh" (pour bash,si je ne me trompe pas. Ou tout autre shell) qui est l'exécutable et tu peux lui envoyer un "ls" via commande

"Exécuter" va lancer le processus. Avec l'exemple ci-dessus, ce sera "python -i"

A+

Jérôme

[Jipété]

- sous Linux tu lances : "bsh" (pour bash,si je ne me trompe pas.

/bin/bash pour être précis (et il vaut mieux l'être, sous Linux).