Discussion :

[Lazagne]

Bonjour à tous,

Voici mon problème :
Je code sous Windows Mobile 2003.
Mon application doit lancer via un clic bouton une autre application et attendre la fin de son exécution pour poursuivre la sienne.
Aucun souci à priori si ce n'est le code suivant...

Code :

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

1
2
3
4
5
6
Process proc = new Process();
          proc.StartInfo.FileName = "un exe quelconque";
          proc.Start();
          this.SendToBack();
          proc.WaitForExit();
          this.BringToFront();

J'exécute ce code depuis une Form. Tout à l'air de bien fonctionner jusqu'à la fermeture du calendrier. Là, le focus sur mon application ne m'est que partiellement rendu : elle s'affiche à nouveau mais ses controles comme le reste de Windows sont gelés. Il ne me reste plus qu'à rebooter l'appareil...

Je sais bien que ça peut paraitre un peu vague mais si quelqu'un a ne serait ce qu'un début de piste à cette bizarerrie d'avance merci !

[winny107]

Je suppose que tu utilise la croix a gauche de la barre windows : sur PDA les application ne sont (par défaut) pas fermé en cliquant sur cette croix mais juste masqués (elles sont toujours présente dans le gestionnaire de tache) du coup ton application attend que l'application soit réellement quittée.
Essaye de quitter proprement ton application ou cherche dans les paramètre système, il y a un paramètre qui permet de quitter les application lors de la fermeture de l'écran principal.

[DonQuiche]

Sinon, lancer le processus depuis un autre thread que l'UI résoudrait, à mon avis, pas mal de problèmes présents et futurs.

[winny107]

Tant qu'a créer un nouveau thread, autant ne pas mettre de WaitForExit() (ca me parait un peu bizarre de créer un thread qui ne fait que lancer un exe lui-même dans un nouveau thread)...
Bref, sauf erreur de ma part, je ne pense pas qu'un nouveau thread soit la solution

[DonQuiche]

Alors permets-moi d'insister.

Appeler WaitForExit depuis le thread UI, c'est une mauvaise pratique : la pompe à messages win32 est gelée (fenêtre pas repeinte, etc) et l'application risque d'être considérée par Windows ou par l'utilisateur comme crashée. C'est typiquement le genre de comportement qui peut créer des problèmes. Ce qu'il faut faire c'est verrouiller l'UI sans bloquer le thread UI (afficher une form modale avec une animation d'avancement).

Pour qu'un thread UI puisse lancer un processus et être notifié de la fin sans bloquer le thread UI, tu as deux façons de faire :
* Souscrire à l'événement Exited (avec EnableRaisingEvents à vrai)
* Lancer un thread qui appellera WaitForExit.

La solution du thread est assez élégante car on réunit dans une même méthode l'initialisation du processus, son exécution et les traitements à faire après son arrêt. C'est transparent, ça fait moins code spaghetti et on n'a pas à penser à se désabonner de l’évènement. Qui plus est, activer les évènements sur les processus à un coût en performances (voir la doc de EnableRasiingEvent, ça doit passer par SetWindowsHook) alors que, en revanche, il me semble que WaitForExit n'a aucun impact.


PS : Lancer le process sur un thread sans utiliser WaitForExit n'aurait aucun intérêt : le thread quitterait sitôt le processus lancé. Ici, on veut détecter la fin du processus.

[Lazagne]

Merci de vos réponses et honte à moi

En effet la croix Windows est la première chose que j'ai testée, en appellant des programmes dont je connaissais le comportement, et d'autres, comme le calendrier, qui continuent à tourner en arrière plan. Dans les deux cas le problème persistait.

J'en avais donc déduit que la sortie du programme n'était pas l'élément qui coinçait et fait tous mes autres tests sur le calendrier...jusquà ce matin où un petit test de l'évènement de sortie sur mon application règle la question.

Problème résolu donc. Merci à DonQuiche !