[R] Exécuter code après kill de l'application

[Clampu]

Bonjour !

Je reviens vers vous pour un problème d'ordre architectural.

J'ai une application AutoIt avec une IHM. Un traitement A puis B est effectué sur un bouton (l'ordre est important). Ce que je souhaite faire c'est effectuer le traitement B même si AutoIt a planté en plein milieu de A, ou si je l'ai sauvagement killé. Et là je ne sais pas trop comment m'y prendre.

Je travail sur la piste suivante :
Je lance un B-bis via un autre threah (un Run) avec une tempo qui exécutera B une fois que l'IHM n'existe plus ET qu'on ne soit pas passé dans le B "normal". Cela fonctionne bien. Le problème est que ce B-bis lancé dans le nouveau thread n'a pas accès aux variables (fichiers ouverts, données ...) utilisées normalement dans B ! N'y a t il pas moyen de dire que le thread B-bis ai accès à la mémoire de l'IHM, tout comme B ? Sinon, il faut que je passe une par une les variables dont j'ai besoin dans B-bis lorsque je fait mon Run("B-bis.exe param1 param2 param3...").

Peut être avez vous une meilleure piste car la mienne ne me parait pas propre. J'espère que j'ai été clair car c'est pas simple à expliquer (j'ai pas mal simplifié). N'hésitez pas à poser des questions !

[Y01]

Bonjour,

Ajouter un bouton pour le traitement B uniquement à l'IHM permettrait de le lancer même si le traitement A plante.

[Clampu]

L'IHM n'existe plus si A a planté puisque j'ai killé l'IHM. De plus le traitement de B est transparent, ce qui fait que l'utilisateur ne doit pas à avoir à le faire lui même : il ne verrai rien se passer et pourrai l'oublier.

[jguinch]

De quel genre de données s'agît-il ?
Tu aurais peut-être intérêt de créer deux exécutables distincts (A et B) et utiliser le planificateur de tâches...

[Clampu]

Le A et le B ont besoin des données de l'IHM plus de données "calculées" auparavant (lecture de fichier par ex). Le B a besoin en plus des données calculées par A. B est dépendant de A

Je n'ai pas accès au planificateur de taches. Il est (comme beaucoup de fonctionnalité) interdit et supprimé du xp que nous avons.

[Y01]

Avec autant de restriction, c'est compliqué.

Une solution (un peu bancale à mon gout) serait d'écrire les informations dans un fichier temporaire afin que le traitement B puisse les utiliser même si A plante.

[Clampu]

En fait B est dépendant du début de A. Donc on peut dire que B n'est pas dépendant de A.

Y01 effectivement cela devrait fonctionner, c'est du même acabit que la solution que j'ai proposé : tu passes par un fichier intermédiaire alors que je passe par par les arguments du Run B-bis. Mais comme tu le dis, cest 2 solutions sont bancales. Quoi que, j'ai un doute sur le fait de partager (via argument ou fichier) des handler de fichier.

Ne connaissez vous pas de moyen de partager automatiquement la mémoire de l'IHM avec son thread fils ?

[Y01]

Le problème dans tous les cas reste le même.

Si l'IHM plante, sa mémoire devrait se vider et donc le traitement B tournerai à blanc !

[Clampu]

Effectivement ça ce servirai à rien de partager la mémoire

Pas le choix donc de passer ces informations avant que l'appli ne plante. Je vais tester

[jguinch]

Tu ne peux pas partager les variables d'un script à l'autre.
Ce que tu peux (seulement) faire c'est transférer des infos d'un script à un autre, en utilisant la méthode de ton choix :
- passer par un fichier intermédiaire (je vois pas pourquoi ce serait bancal)
- passer par une petite base de données (en fonction des données traitées)
- passer par MailSlot (un UDF est disponible)
- passer par TCP (je le met même si je ne l'utiliserait pas)

Après, faut voir les infos que tu veux faire passer entre les 2 programmes...
Si c'est du texte sur plusieurs lignes, oublie les paramètres de lancement.
Si c'est des "petites" infos, genre valeurs ou petites chaînes, tu peux utilisater les paramètres de lancement ($cmdline) et/ou les variable d'environnement (script A utilise EnvSet et script B utilise EnvGet), mais uniquement au lancement du script B.

Autre possibilité à envisager : éviter que le script plante.... (ah ah, fallait y penser à celle-là )

[Y01]

- passer par un fichier intermédiaire (je vois pas pourquoi ce serait bancal)

Tout simplement parce que les informations transférées d'un traitement à l'autre peuvent être sensible (identifiants ou autres)

[Clampu]

Je vais tester avec un .ini. Effectivement, les infos ne sont pas idéales pour passer en lignes de commande et il n'y a pas de données confidentielles.

Merci à vous je vous tiens au courant

[Clampu]

Bon ba ... ça fonctionne ! Merci beaucoup à vous 2

[jguinch]

Si le sujet est résolu, n'oublie pas la balise [R] dans le titre de ton premier message.

[Clampu]

Le sujet est quasiment résolu. En fait j'ai un dernier problème auquel je n'ai pas eu de réponse.

Concernant le passage des Handle de fichier, avec vous une expérience là dessus ? J'ai écrit le Handle dans le fichier avec un String() puis l'ai chargé avec un Handle() mais ça ne fonctionne pas, j'ai @error à 1. Cela ne me semble pas illogique, mais j'aurai aimé fermer les fichiers ouverts pas A dans B-bis. Après, je ne sais pas si c'est indispensable.

[Y01]

B-Bis doit fermer un fichier ouvert par A ?

Si c'est bien le problème, un AdminRequired devrait régler ce problème (si c'est faisable).

[Clampu]

Oui c'est ça. Mais non pas possible, les utilisateurs ne sont pas admins.

[Y01]

Généralement quand un fichier est ouvert par une application et qu'une autre application veux y accéder, Windows l'envoie boulet donc je doute que ça soit faisable sans droits d'admin.

[Clampu]

Je laisse comme ça alors et passe en [R]. Ça n'a pas l'air de poser vraiment de problèmes. En tous cas merci de votre aide précieuse