walkson a écrit :Bonjour,
Au risque de dire une grosse bêtise, il me semble que Aut2exe.exe est portable donc pas d'installation et peut se mettre n'importe où (à confirmer par les experts...)
Oui c'est portable, pas d'installation. Mais j'ai utilisé cette méthode (je me rappelle maintenant !
) pour recompiler mon code externe à l'application chaque fois que je faisait un test, dans le cas ou j'étais sur un poste avec autoit (autrement dis : un poste de développement). Cela fonctionnait bien sur le mien puisque la compilation était possible, par contre sur un poste avec un vieil autoit, la compilation ne fonctionnait pas. Au pire, je peux utiliser la macro @UserName pour choisir quand recompiler ou non mon code !
orax a écrit :Il y a FileGetVersion mais si Aut2exe.exe est bien portable alors il serait peut-être plus simple de copier la version qui convient avec le script.
Oui mais en fait je ne souhaite pas compiler lorsque c'est un autre poste. Donc plus de problème
. Merci pour FileGetVersion ça peut servir.
Tlem a écrit :Un truc me chagrine. Vous dites dans votre premier message que le script fonctionne sur un machine ou AutoIt n'est pas installé ...
Vous nous auriez fait un mensonge.
Envoyé de mon appareil mobile avec Tapatalk.
Je n'ai pas menti, ça fonctionne correctement sur un poste sans autoit, puisque je ne recompile pas tous mon code (FileExists renvoie false, logique). En fait, ça plantait lorsque je recompilait avec un vieux autoit.
jchd a écrit :Quite à passer pour dépressif, je dois dire qu'il y a plusieurs autres points qui me chagrinnent dans ces deux fils de discussion.
1) On nous dit que A "plante" : c'est donc ce problème-là qu'il faut résoudre. Point.
2) Si le parc doit comprendre une installation d'AutoIt, il est logique (voire impératif) d'assurer l'homogénéité en termes de version. Simplement copier un Aut2Exe.exe récent sur une installation plus ancienne ne peut fonctionner de façon satisfaisante.
3) Pourquoi parler d'un B-bis ? Un B tout court suffit, lancé après A par un lanceur (RunWait de A puis Run de B).
4) Pourquoi ne pas employer un fichier recevant les données de A ?
5) On a demandé quelques infos sur la structure et le volume de ces données, sans réponse.
6) Si pour une raison ou une autre un simple fichier ne présente pas les garanties d'intégrité souhaitées, une simple base SQLite serait la bonne solution.
7) En quoi bidouiller une recompilation à la volée est-il moins bancal que de passer par une BdD (ou un bête fichier si les données ont une structure simple) ?
1) Oui je le sais bien, mais ce n'est pas possible dans l'état des choses. Par exemple, l'application pilotée par autoit plante de manière aléatoire. J'ai beau mettre des tests de vérification avant d'utiliser mes ControlFocus, s'il y a un plantage entre l'exécution des 2 lignes, ça crash. Je préfère avoir un parachute (B).
2) N'a plus lieu d'être vu que je souhaite compiler uniquement lorsque c'est sur mon poste.
3) Oui, c'est juste que dans B j'ai un fonctionnement légèrement différent en fonction de la manière dont il est lancé. Mais soit.
4) C'est fait justement, sur conseils de jguinch et Y01
5) Ce n'est pas pertinent, mais il y a une dizaine de couples clé/valeur (des dates, des booleans, des chaines, des id de fichiers ...). De plus, j'ai répondu sur l'autre thread me semble-t-il :
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
6) Oui c'est la bonne solution. Mais ces infos ne sont pas confidentielles, un fichier ini est suffisant. Je garde sous le coude cette solution.
7) Tu as raison, mais ce n'est que du confort pour moi finalement. Je peux m'en passer.
Merci de votre aide à tous, et désolé de m'être mélangé les pinceaux en indiquant que c'était lié à l'autre problème.
