AutoIt Français

Bonjour,

Je rencontre un petit soucis avec l'usage de l'éditeur SciTE. Je ne sais pas du tout si le forum est habilité à agir sur ce type de problème, je me permet de le présenter au cas où.

J'utilise actuellement la fonction AU3 IsDeclared() pour voir si mes variables sont bien déclarés avant utilisation, notamment car je souhaiterais que certaines d'entre elles ne soient utilisés qu'au second passage d'une boucle While - ce qui sous-entends que les variables vérifiés dans IsDeclared() se déclarent lors du premier passage, en bas de code, tandis que les fonctions IsDeclared() sont présentes en haut du code (style procédural, évidemment).

Cependant, maintenant, à chaque compilation, j'ai des warnings qui me provoquent de nombreux sauts de ligne car le programme ne voit évidemment pas mon intention, et considère donc que les variables sont potentiellement utilisées sans avoir été initialisées.

Existe-t-il un moyen d'empêcher ça ou d'épurer l'affichage des warnings ?

C'est un choix de design potentiellement dangereux et très probablement complètement inutile.
Peut-on voir un exemple de code (raisonnablement concis) où la chose se justifie ?

Sinon en dernier recours et seulement si toutes les divinités de la logique avouent leur impuissance, on peut éventuellement utiliser #forcedef mais c'est un peu comme confier à un pédicure son pied rongé par la gangrène.

En fait, cette question fait suite à ce sujet : https://www.autoitscript.fr/forum/viewt ... =3&t=15102

Résumé TL;DR : J'ai un processus parent qui exécute un processus enfant dans le but que si le processus enfant crash, le processus parent puisse handle les erreurs non-COM.

Dépendant de comment l'erreur va être handle par le processus parent, les variables contenant les connexions SQL ne seront peut être pas définit.

Comme le processus parent s'exécute AVANT le processus enfant et que c'est le processus enfant qui contient les GUI Input contenant les identifiants de la base de donnée, je les stock et les fait communiquer entre les deux processus. Cependant, le processus parent ne va définir la connexion SQL pour ne pas surcharger les serveurs que lors du crash du processus enfant (qui lui possède les connexions SQL active, mais qui au crash, les fermera automatiquement). D'où le fait que dans le While, un IsDefined() est présent AVANT la déclaration des variables contenant les connexions SQL.

A noter que ce n'est pas le seul cas : Chaque processus envois des données SQL pour avertir sur une interface web qu'il est bien en train de tourner. Cette information doit transité avant tout traitement (il peut y avoir un nombre infini de processus, qui s'auto-attribue un nom de traitement selon un algorithme interne), car le traitement est susceptible de faire crash le programme (d'autant que le programme peut intégrer via FTP des scripts .au3 afin d'obtenir de nouvelles fonctionnalités au cœur du programme sans avoir à le relancer). Cependant, ces informations sont transmises avant l'ouverture des connexions SQL, justement si la variable passe le test IsDefined() (ceci dans le but de pouvoir mettre en évidence les erreurs non-COM lié au SQL du processus enfant).

Entre outre, dans cet exemple, si les variables SQL ne sont pas défini (ou défini dans un scope inaccessible), le script va simplement les redéfinir, si les valeurs du GUI ont été au préalable définit (Parce que le programme que je développe prends en argument GUI les valeurs de connexions à la BDD, pour permettre de les masquer. C'est ma manière de me sécuriser contre la décompilation).

J'utilise aussi cette façon de travailler via un UDF que j'ai moi même fait sur SQL qui permet d'utiliser un KeepAlive() pour vérifier si la connexion SQL est encore maintenue. Pour ça, je défini une variable, variable qui doit passer le test IsDefined() en début de script aussi, du coup.

Un exemple concret de traitement serait le suivant (même si en vérité, c'est plus long en comprenant les GUI) :


Dans ce code, la ligne _MySQLQuery() aura un warning. Attention, c'est très simplifié (le cœur du programme dépasse les 8000 lignes de code, c'est assez difficile d'en extraire un exemple réduit et fonctionnel). Je ne prends pas vraiment le bon exemple car lors de mes vérifications de la variable $sql, je la redéfinis en vérité. Mais c'est pour montrer le type de cas de figure.

A noter aussi que si l'erreur non COM fait suite à une erreur COM SQL, le programme parent doit transformer sa sortie vers du FTP (qui sera via une tâche CRON de l'interface web intégrer comme si elle venait du programme), ce qui vérifie encore l'existence d'autres valeurs et, si cela ne fonctionne toujours pas, viendra écrire l'erreur dans un fichier .txt en local qui sera renvoyé via SQL au relancement du programme. ça fais énormément de variables.

En somme, tout marche, c'est juste qu'au niveau du développement, il y a énormément de sauts de ligne suite au SyntaxCheck Prod effectué par SciTE.

Je vois (très à peu près).
Si je comprends bien, ton parent lance un ou des fils qui définissent leur contexte dans leur coin (connexion BdD et autres) et font leur mayonnaise isolément, y compris en ajoutant des bouts de code "au vol" selon les besoins. C'est ce qui rend la chose compliquée.

A défaut de ré-architecturer l'ensemble de ton usine à gaz de façon monolithique — ce que tu n'as probablement pas trop envie de faire à ce stade — tu peux utiliser #forcedef comme dit plus haut.

Ceci dit, je vois mal ce qui t'empêche de faire ceci : Tu peux même placer ta déclaration avant la boucle While, une fois pour toutes.
Qu'ai-je raté ?

Hello,

Une refonte est possible et prévue, je me demandais juste s'il y avait un moyen d'empêcher SyntaxCheck Prod de produire des écarts de ligne comme ça. Je vais voir du coté de #forcedef (dont les infos se trouvent ici pour ceux qui lieraient le thread : https://www.autoitscript.fr/autoit3/doc ... 3check.htm). Sinon, en voyant l'exemple de #forcedef, je ne sais pas si je ne ferais pas mieux d'initialiser mes variables à FALSE, et d'utiliser VarGetType() pour savoir si elles sont initialisées comme attendues par le système. Tout ça juste pour éviter la surcharge de SyntaxCheck Prod !

Pour répondre à ta question : Ce bout de code est issu du processus parent. Les GUICtrlCreateInput se situent dans le processus enfant #1 (qui sert aussi d'IHM, le processus parent étant totalement masqué), lesquelles sont utilisés pour définir les credentials SQL. Donc, impossible ici de redéfinir $sql sans au préalable vérifier que ces variables n'aient pas été retournés par le processus enfant #1 et stocker à nouveau dans le processus parent (a moins que j'ai mal compris le scope Global et que les variables en Global seraient partagés entre les différents processus ? J'en doute). En gros, impossible de redéfinir $sql dans le processus parent si le logiciel vient à crash avant que l'utilisateur ait saisi les identifiants SQL - et cela ferait potentiellement crash le processus parent par la même occasion (avec une erreur impossible à handle !). Plutôt que d'initialiser des variables à vide et de vérifier leur contenu, je préfère simplement les initialiser à la bonne valeur et vérifier simplement si elles ont étés initialisées.. mais dans ce fonctionnement on retombe sur le soucis du SyntaxCheck Prod.

Comment aurais-tu architecturer cette application ? Je trouve l'architecture et la découpe que j'ai effectué en accord avec le fonctionnement souhaité, mais je ne connais pas encore toutes les subtilités d'Autoit.

Ce que je ne comprends pas c'est comment et où $sql est déclarée et initialisée dans le cas où IsDeclared renvoie 1 (globale).
Si $sql est bien déclarée en global, tu ne dois pas avoir de warning. Sinon, tu la déclares ainsi, tu l'initialises à NULL (ou 0) et, quand tu en as besoin, tu l'initialises avec ce qui t'es remonté du fils et tu enquilles ta suite. Ensuite tu la remets à NULL (ou 0).

Mais sauf si tu as plusieurs endroits où cette variable est utilisée, tu peux juste la mettre en local dans la fonction qui contient ta boucle While.

Global, c'est à l'intérieur d'un process, aucune communication directe possible avec l'extérieur.

Je n'en sais pas assez sur ton contexte précis et tes besoins pour émettre un quelconque avis plus détaillé. Et je manque furieusement de temps pour m'immerger dans ce que tu as déjà mis sur pieds.

Hello,

Pour info, le soucis a disparu avec l'usage de #forcedef, je vais voir maintenant comment je préfère gérer de mon coté (de toute façon, a terme avec la refonte, je pense que ce soucis ne sera même plus d'actualité). Inutile d'aller plus loin sur le sujet. Merci !

Je réponds juste afin de répondre à ta curiosité :
- $sql est définit dans le processus enfant #1 grâce à des valeurs fournis dans des GUI Inputs et avec pour valeur un Objet ADODB en scope global (mais donc, non accessible par le parent ou ses futurs enfants).
- Au même instant, le processus enfant #1 envoi au processus parent (qu'on va plutôt appeler "processus cœur") les credentials SQL. Ces données seront stockés sous forme de variable, mais $sql (dans le processus cœur ! Il y a donc 2 $sql) ne sera PAS redéfinit tant qu'une erreur non-COM ne sera pas survenue (une erreur fatale faisant planter un processus), afin d'éviter la surcharge de connexion.
- A noter que le processus "cœur" est installé sur différents serveurs en interne, car nous travaillons avec plusieurs sous-réseaux. Chaque processus coeur se créer donc un nom unique, via un algorithme interne, pour pouvoir être piloter à distance, via une seule interface web). D'où l'utilité de n'ouvrir la connexion SQL que si nécessaire.
- Le processus enfant #1 va créer x processus enfant et devenir à son tour un processus parent tout en restant fils du processus cœur.
- Tout ce qui sera envoyé par les processus "petit-enfant" seront remontés au processus cœur par le biais du processus enfant #1, donc, les erreurs non-COM des processus enfant vont déclencher la création d'un lien SQL pour mettre l'erreur en base (ne surtout pas se servir du code exemple que j'ai fournis, du coup, car il ne colle pas).

A partir du moment ou le lien SQL est fournis par le processus enfant #1, le processus cœur a la possibilité de recevoir la commande via l'interface web pour relancer le processus enfant #1 et ses enfants en cas de crash, avec un timer de reconnexion automatique à la base SQL. C'est un peu comme un générateur de secours qui lancerait un programme principal qui sous-traiterait ses actions par des processus "petit-enfant".