Sur un projet d'automatisation d'installations de Windows 7 je tente de faire afficher la fenêtre permettant d'entrer un code de licence. Pour ce faire j'essaye d'utiliser "slui.exe" qui emmène directement sur la-dite fenêtre.
Hélas toutes mes tentatives restent infructueuses il semble que ce programme refuse de se lancer dans un script alors qu'il se lance très bien en direct (en cliquant dessus par exemple) ou dans l'invite de commande.
► Afficher le texte
RunWait(@ComSpec & " /k slui")
RunWait(@ComSpec & " /k slui.exe")
RunWait("slui.exe")
RunWait("C:\Windows\System32\slui.exe")
Aucun de ces tests n'est concluant. Qu'est-ce qui m'a échappé ?
Modifié en dernier par BlackWater le mar. 05 janv. 2016 15:10, modifié 1 fois.
TommyDDR: slui.exe se situe en effet dans System32.
orax : Donc le soucis se situerait au niveau de l'OS seven. L'utilisation du slmgr ipk est une option envisageable, cela oblige cependant a créer une boite de dialogue avec un champ à remplir pour le numéro de licence (en effet dans mes contraintes les techniciens doivent entrer le code licence à la main).
Ah... s'il faut créer une boîte de dialogue alors autant utiliser "slui". J'avais proposé cette alternative puisque je pensais que l'entrée du code serait automatisée.
Avec ShellExecuteWait c'est pareil ?
De petits détails peuvent faire toute la différence. — Quand la boule de neige commence à rouler… poussez-la. (Columbo)
Me retourne une erreur (Windows ne trouve pas C:\Windows\System32\slui.exe)
ShellExecuteWait("C:\Windows\System32\slui.exe")
Idem, comme si le programme était introuvable alors qu'il se trouve bien dans ce répertoire (j'ai re-vérifié), se pourrait-il qu'il y ai un conflit de chemin entre un OS 32 et un 64 bits ?
Cela semble en effet fonctionner pour slui.exe (ainsi que pour la plupart des fenetres Windows accessibles par des programmes stockés dans System32) à la compilation en version X64 (pour mon système en 64bits).
