Question sur System.Diagnostics.Process

Bonjour tout le monde !

J'ai ce code :

Code:

---

1 2 3 4 5 6 7

/* Lancement de Reprodesk et des fichiers à visualiser */ System.Diagnostics.Process MyProc_ = new System.Diagnostics.Process(); MyProc_.StartInfo.UseShellExecute = true; MyProc_.StartInfo.Arguments = strReprodeskParam; MyProc_.StartInfo.FileName = "c:\\ocerd\\job.exe"; MyProc_.Start(); MyProc_.Close();

---

Ce code me lance donc une instance de l'application job.exe, avec en paramètre une liste de fichier à ouvrir, contenue dans strReprodeskParam.

En temps normal, cette application (job.exe), je l'utilisais à partir d'un code vb, dans lequel j'avais une boucle qui scrutait un répertoire et remplacait strReprodeskParam par un chemin d'accès vers un fichier.

Résultat de tout ca, mon job.exe, ouvrait dans une meme fenetre, tous les fichiers demandés.

Une fois que la commande : MyProc_.Start(), est lancée, on a dans le gestionnaire des taches une instance de Job.exe, aussi, j'aurai aimé pouvoir ré utiliser cette instance de Job.exe, et donc de MyProc_, pour modifier la variable strReprodeskParam. Est ce possible ?

Merci d'avance

à priori non

si c'est toi qui a écrit job.exe, il est alors possible de coder un dialogue entre les 2 applications

malheureusement ce n'est pas moi qui ai codé ce Job.exe.

Y a t il une autre méthode pour appeler une application windows autrement qu'en utilisant System.Diagnostic.Process?

shell()

mais ca revient à peu près au même, ca appelle process.start :D

de toutes facon les arguments passés à un exe ne peuvent etre passés qu'en appelant l'exe, c'est windows qu'est comme ca depuis des années ...

certains exe voyent qu'ils ont déjà une instance en route et n'en démarre pas une 2ème mais disent à la 1ère d'ouvrir des fichiers de plus

Si tu veux l'argument que je veux passer à mon Job.exe est constitué de chemins d'accès, séparés par des " ", exemple:

Code:

---

strReprodeskParam = "c:\\test.tif c:\\test2.tif....c:\\test50.tif";

---

En temps normal sur windows, je double clique sur un fichier .tif, et ca m'ouvre job.exe avec mon fichier .tif. Si je double clique sur un second fichier .tif et ce sans fermer Job.exe, ce second fichier .tif est ouvert dans la meme fenetre job.exe que le premier, et ce sur la même instance.

Avec les limitations sur les chaines de caractères et windows, je ne peux pas avoir une variable strReprodeskParam avec un nbre de caractères illimité.

ce que j'ai éventuellement pensé, mais ca ne marche pas bien, c'est de boucler sur le code que j'ai ennoncé au premier post, de facon à n'avoir qu'un seul chemin d'accès dans la variable strReprodeskParam, et donc en gros, tant qu'il y a des fichiers dans un répertoire, mon appli boucle sur ces fichiers, et me lance autant de fois que necessaire Job.exe, comme ca si j'ai tous mes fichiers dans mon appli.

En vb, cette solution fonctionne, mais en .net je n'arrive pas à la refaire.

En vb, mon code était :

Code:

---

Shell Loc_Reprodesk & " " & l_argslist, vbNormalFocus

---

ou Loc_Reprodesk = c:/ocerd/job.exe
l_arglist = chemin d'accès vers mon fichier.

Alors question :

Est ce que la commande vb Shel() est identique à celle de .net ?

oui j'allais d'ailleurs te le proposer vu que job.Exe s'occupe d'ouvrir les fichiers dans le meme processus
donc pas besoin d'appeler l'exe, mais juste les fichiers chacun leur tour

j'ai déjà testé shell en .net et ca marche bien en théorie, pour la syntaxe, l'intellisense te l'explique ...

shell("http://monsite.fr") ouvre le navigateur par défaut avec le site
shell("mailto:adr@mail.com") ouvre le mailreader par défaut avec un nouveau mail
shell("chemin\fichier.doc") ouvre word
etc...

Bon eh bien après essai avec la méthode Shel(); il s'avère qu'elle exécute ce que je veux et de la bonne façon.

A savoir pour l'utiliser qu'il faut inclure un using Microsoft.VisualBasic et qu'il faut l'ajouter aux références du projet.

Inutile d'ajouter aux référence le fichier mscorlib.dll, qui est automatiquement joint avec Microsoft.visualbasic.

Merci encore!

je vais me faire engueuler si on voit que j'ai réussi à faire importer visualbasic.dll à un c#ien :lol:

le code de shell se terminant par un process.start, ca se trouve avec process.start(fichier) ca aurait marché aussi ...