J'imagine que c'est pour que la fonction puisse avoir des retours différents selon le déroulement du script ou autre
La situation est la même en mode événementiel (où la question se pose souvent)
Thierry ça fait longtemps que tu n'as pas codé ?
" L'échec est le fondement de la réussite. " (Lao-Tseu ) " Plus ça rate, plus on a de chances que ça marche " (les Shadoks )
Pour pouvoir coder, il faut un peu de temps. Depuis un bon moment, cette denrée me fait cruellement défaut. ^^
Concernant l'argument de la fonction, si celles-ci est utilisée en dehors du HotKeySet ok, sinon, aucun intérêt.
A ce moment là, le passage de valeur peut simplement ce faire par variable globale.
Je ne suis pas d'accord, on défini clairement que $bTest doit être égal à false si non renseigné, avec le if/else en exemple on doit le définir 2 fois, ce qui ne me semble pas logique. Et l'écriture "paramètre optionnel" devient même inutile avec cette technique.
HotKeySet("{Esc}", "_Exit")
HotKeySet("{F9}", Test)
Test()
Test(False)
Test(True)
While 1
Sleep(10)
WEnd
Func Test($bTest = Default)
Static $cTest = False
ConsoleWrite("Invocation de Test " & (@NumParams ? "avec " & $bTest : "sans argument.") & @CRLF)
If @NumParams Then
$cTest = $bTest
Else
$cTest = Not $cTest
EndIf
ConsoleWrite("La variable statique est maintenant " & $cTest & @CRLF)
EndFunc
Func _Exit()
Exit
EndFunc
Pour la démo je fais la négation de la variable statique lorsque la fonction est appelée sans argument, mais on est libre d'adapter à tout autre chose.
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
Voià ce que dit la doc pour HotKeySet: The called function can not be given parameters. They will be ignored.
@HotKeyPressed macro can be used inside the function to handle several keys in the same function.
Donc pour moi c'est très clair.
Le comportement est le même pour d'autres fonctions, comme AdlibRegister ou GUICtrlSetOnEvent, et c'est à chaque fois expliqué dans la doc : You can not call a function using parameters.
Donc à partir du moment où on est prévenu, je ne pense pas qu'on puisse dire que c'est un bug.
Par contre, je suis entièrement d'accord avec le fait que le paramètre optionnel pourrait/devrait prendre la valeur par défaut. Mais dans ce cas, qu'en sera t-il si le paramètre n'est pas optionnel ? Donc l'utilisation @NumParams ne me paraît pas mauvaise...
Le script, ça fait gagner beaucoup de temps... à condition d'en avoir beaucoup devant soi !
Tlem a écrit :Concernant l'argument de la fonction, si celles-ci est utilisée en dehors du HotKeySet ok, sinon, aucun intérêt.
A ce moment là, le passage de valeur peut simplement ce faire par variable globale.
Absolument d'accord. Et ça évite les prises de tête à essayer à toute force de faire rentrer une forme carrée dans un trou rond - ce qui est toujours possible avec un bon marteau
" L'échec est le fondement de la réussite. " (Lao-Tseu ) " Plus ça rate, plus on a de chances que ça marche " (les Shadoks )
Désolé, mais l'utilisation de variables globales dans ce cas précis n'est pas la solution la plus propre. Les variables statiques sont bien plus "propres" et ce paradigme s'applique correctement dans du code complexe, où le foisonnement des variables globales devient vite rédhibitoire.
Par ailleurs il n'y a aucun problème à invoquer par HotKeySet, AdLibRegister, ... une fonction spécifiant des paramètres optionnels.
Valik était un fervent supporter (dans le genre "ultra") de ces pratiques et je suis tout à fait de son avis.
Même si AutoIt n'est pas un design "OO" à la base, il est de beaucoup préférable de disposer de fonctions agissant comme des méthodes pour ce type d'opération. Le code nécessaire est à peine plus lourd et la manipulation de variables "internes" est rendue étanche à l'eau et aux poussières.
Bon, je dis ça mais il ne faut pas non plus s'arc-bouter sur une idée fixe et vouloir, par exemple, "objettiser" toute une GUI AutoIt complexe pour le plaisir. Mais si une façon simple et robuste de coder est disponible sans contorsion particulière, autant l'utiliser. C'est quand même mieux que du Basic des années 70, avec 4317 variables forcément globales et un seul sac de 13504 lignes de nouilles à GOTOs pour fil d'Ariane.
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
@jchd : Pourquoi ne pas simplement affecter les valeurs par défaut des paramètres optionnels ?
Est-ce une réelle contrainte de code derrière ou cela pourrait-il être fait "facilement" ?
Je n'ai aucune vue sur les implications de ce changement et ça fait partie du jardin privé de Jon, seul développeur à l'heure actuelle et fort occupé à fouetter d'autres chats. Ceci dit je ne crois pas que ça serait aussi simple que ça sauf dans le cas de variables "plates" (local, copy on write ou référence).
Il faut bien voir qu'AutoIt n'a pas été développé à la base comme un projet de langage ambitieux et bien structuré, mais plutôt comme une chouette bidouille permettant de simplifier des tâches d'administration et qui a connu un développement en spirale, parfois un poil anarchique. Du coup et à défaut d'un plan bien clair, il y a beaucoup de choix qui mériteraient d'être revisités. Cela ne pourrait se faire qu'avec une révision majeure type AU4 et nombre de "code breaking changes" et ce n'est pas prêt d'arriver.
On peut percevoir AutoIt comme en phase préliminaire de sclérose, mais il faut tout de même lui reconnaître une belle efficacité dans nombre de cas d'utilisation. Donc vivre avec en bonne intelligence avec ses creux et ses bosses ou faire le choix d'une autre plate-forme plus carrée.
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.