[R] Bug sur #include avec guillemets, ou pas ?

[hilow]

Bonsoir. Est-ce que quelqu'un a connaissance d'un bug sur #include en utilisant les guillemets ?

J'ai pour habitude de découper mes projets en plusieurs fichiers (ici, donc, plusieurs .au3). Prenons un projet sous "C:\dev\machin" avec deux fichiers : ui.au3 et main.au3.

Si je déclare la dépendance sans chemin, une erreur m'indique que ui.au3 est introuvable :
#include "ui.au3"

Par contre, si j'indique le chemin (absolu), tout va bien :
#include "C:\dev\machin\ui.au3"

Même si le PATH de recherche est inversé avec <>, j'ai tout de même essayé (#include <ui.au3>) et idem : erreur. Mais là, c'est moins important puisqu'on n'est pas censé l'utiliser pour des dépendances spécifiques au projet.

[Utilisateur 4536 supprimé]

Tu es sûr qu'ils sont dans le même dossier ? Ou que tu n'as pas copié ailleurs l'un des deux pendant que tu l'éditais ? Par exemple, moi ça m'était arrivé, j'étais en train d'éditer un fichier, je l'ai copié (pas coupé) ailleurs, sans avoir fermé Scite, puis j'ai fais des includes, le problème c'est que ça marchait pas vu que j'étais en train d'éditer le premier fichier, il n'avait pas été déplacé lui, simplement copié. Simple erreur d'inattention.

[hilow]

A priori, oui, mais je vais refaire un test pour être sûr... et reviens te dire...

--
EDIT : alors, résultat :

Sur ce quick test, ça marche :

Code : Tout sélectionner

; ui.au3
#include <ButtonConstants.au3>
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>

#Region ### START Koda GUI section ### Form=H:\TMP\test\ui.kxf
Global $Form1 = GUICreate("Form1", 623, 449, 192, 114)
Global $Button1 = GUICtrlCreateButton("Button1", 272, 144, 75, 25)
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###
 

Code : Tout sélectionner

; main.au3
#include "ui.au3"

While 1
    $nMsg = GUIGetMsg()
    Switch $nMsg
        Case $GUI_EVENT_CLOSE
            Exit

    EndSwitch
WEnd
 

Mais pas sur mon projet Alors, puisque le chemin est long, je me suis dit que ça venait de ça et en ai fait une copie au même endroit que le test ci-dessus et idem : erreur :

>Running AU3Check (1.54.22.0) from:C:\Program Files\AutoIt3
H:\TMP\medor\main.au3(4,10) : ERROR: can't open include file "ui.au3".
#include "ui.au3"
~~~~~~~~~^

[blacksoul305]

Ça fait quand même plusieurs sujets où vous oubliez la balise [..] et [R] dans votre titre, vous devriez faire gaffe.

[hilow]

Oui, sorry, je l'ajoute. C'est que je suis sur 150 forums avec chacun leurs règles diverses et variées. Je corrige de suite...

--
EDIT : OK, résolu Alors, je ne sais pas pourquoi, mais je pense avoir trouvé. J'ai à un moment édité mon fichier main.au3 sous Notepad++ et l'ai enregistré en encodage UTF-8 (bien que tout le jeu de caractère passe en ANSI), et c'est apparemment ce qui posait problème à AU3Check. J'ai réenregistré ce fichier en ANSI et c'est maintenant OK. Je pense donc qu'il y a un bug à caractériser plus précisément, là !

--
EDIT #2 : petit ajout si ça peut aider quelqu'un dans le même cas ou permettre de cerner le bug (puisqu'il y en a bel et bien un) :

Si je prends ce fichier minimaliste :

Code : Tout sélectionner

; vérif
#include "ui.au3"
 

et que je l'encode en UTF-8, AU3Check ne trouve pas ui.au3 via l'include. Si je le réencode en ANSI sans prendre garde que tous les caractères accentués soient bien convertis en leur équivalent ANSI (par exemple le "e" accentué de "vérif" qui resterait en UTF-8 donnerait "vérif" en ANSI), ça continue de perturber AU3Check ; et même l'obfuscator qui prend alors mon fichier pour de l'UTF-8 sans BOM. Il faut donc convertir en ANSI puis réenregistrer encodé en ANSI si l'éditeur ne fait pas les deux opérations de lui-même. Voilou ! Bonne soirée