AutoIt Français

Bonjour,

Mon programme (exe) autoit ne fonctionne pas sur tous les postes de mon service : il fonctionne sur les postes ayant le dernier autoit installé, les postes n'ayant pas autoit d'installé, mais pas sur les postes ayant un viel autoit d'installé !

J'ai un message indiquant qu'il ne trouve pas MsgBoxConstant. Dans le répertoire include d'autoit, il y a effectivement une différence entre les 2 installations (ce fichier est présent sur les nouvelles version d'autoit mais pas les anciennes). Autre message : sur l'opérateur ternaire ( X ? Y : Z) qui n'est pas implémenté dans l'ancienne version.
Le truc, c'est que la version est compilée je ne vois pas pourquoi ça changerai quelque-chose que le code ne soit pas pris en compte par la version actuelle ...

Une idée du pourquoi de la chose ? Une option dans le compilateur ? Autre chose ?
Merci

Bonsoir.
Effectivement, un code compilé est indépendant d'une quelconque installation d'AutoIt puisque sur un PC non équipé d'AutoIt le code fonctionne. Un code compilé fait appel à l'interpréteur AutoIt utilisé pour la compilation puisqu'il est compilé avec ...

A moins que votre Exe ne lance explicitement une ligne de code AutoIt à exécuter avec l'AutoIt local ou fasse appel à une clé de base de registre propre à AutoIt.

En tout état de cause, a moins d'une découverte inopinée d'un bug non encore connu (peut être avec la macro @AutoItExe), il serait intéressant de voir votre code afin de le tester ou a défaut de vous indiquer d’où vient l'erreur.

En fait, je n'ai pas bien creusé longtemps (je devais être fatigué ...). J'ai effectivement une ligne de code qui peut poser problème dans le cas d'une vielle installation :
En gros j'ai une re-compilation qui s'effectue à chaque fois (lié au problème présenté ici). Y a t il un moyen de savoir quelle version est installée sur le poste ? Sauf erreur de ma part, la macro @AutoItVersion ne correspond pas exactement à ce que je recherche, puisque qu'elle renvoi la version utilisée pour compiler et non pas celle utilisée par le pc. J'ai 3.3.12.0 en exécution sur un pc avec un autoit en 3.0, par exemple.

Il y aurai pas un moyen de faire ça ? une ligne dans le registre ou lire la version ?

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...)

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.

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.

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) ?

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.