[..] Identifiant du fenêtre de l'explorateur ouverte.

[Patrick22]

Bonjour, ou bonsoir, tout le monde,

Je bute sur un problème péniiible : Comment connaître sûrement l'identifiant d'une fenêtre de l'explorateur ouverte à partir de son chemin ?

Pour l'instant je ne vois que ShellExecute($sChemin) ou Run("Explorer """ & $sChemin & """") afin d'ouvrir la fenêtre. Mais elles ne renvoient pas le handle de la fenêtre.

On l'obtient ensuite avec un $handle = WinWait($NomDossier) par exemple mais cela n'a rien de sûr. Il suffirait qu'une autre fenêtre ait le même nom et ... perdu ! Je n'aurais pas le handle de la bonne fenêtre.

De plus, suivant les paramétrages des options d'affichage, le contenu de la barre n'est pas le même.

Après avoir beaucoup fouillé les forums, je crains qu'il n'y ait pas de solution 100% fiable hélas , mais si quelqu'un à idée , je prendrais avec plaisir .

Je continue à chercher des pistes. Peut-être avec une WinList() avant l'ouverture, une autre après puis comparer les deux. Et vérifier la présence de $Dossier dans la ou les fenêtres nouvelles détectées. Il n'y aurait pas une solution plus simple et plus propre ? Avec des instructions AutoIt que je ne connais pas encore ?

[jguinch]

Quel est le but ? Qu'as-tu besoin d'automatiser dans l'explorateur ?
Il y a peut-être d'autres solutions...

[timmalos]

Voici comment récuperer une fenetre à partir de son processusID (retourné par Run):

Code : Tout sélectionner

Func _GetHwndFromPID($PID)
    $hWnd = 0
    $stPID = DllStructCreate("int")
    Do
        $winlist2 = WinList()
        For $i = 1 To $winlist2[0][0]
            If $winlist2[$i][0] <> "" Then
                DllCall("user32.dll", "int", "GetWindowThreadProcessId", "hwnd", $winlist2[$i][1], "ptr", DllStructGetPtr($stPID))
                If DllStructGetData($stPID, 1) = $PID Then
                    $hWnd = $winlist2[$i][1]
                    ExitLoop
                EndIf
            EndIf
        Next
        Sleep(100)
    Until $hWnd <> 0
    Return $hWnd
EndFunc ;==>_GetHwndFromPID

[Patrick22]

Bonjour @timmalos,

J'ai essayé le code mais ça beuugue on dirait.
Il reste dans une boucle infernale parce que la ligne :

Code : Tout sélectionner

If DllStructGetData($stPID, 1) = $PID Then

n'est jamais vrai !
J'ai placé des traces et le handle de la fenêtre créée est pourtant bien existant.

[Patrick22]

J'avais vite répondu parce que je te voyais en ligne mais entretemps tu as disparu je suis donc retourné pousser les tests.
Résultat :
Le process lancé par le run ne reste pas longtemps actif, pas assez pour retrouver la fenêtre créée. Dommage.

[Patrick22]

@jguinch, je cherche ça pour sécuriser les actions entreprises ensuite dans la fenêtre ouverte. Si ce n'est pas la bonne, bonjour les dégâts !

[Patrick22]

Bon , j'ai codé une fonction OuvrirDossier() qui sécurise une ouverture de fenêtre de l'explorateur (80 lignes commentaires inclus, 30 lignes sinon). J'aimerais la partager avec ceux que ça peut intéresser.
Comment procéder :

• Rester dans ce forum ?
  Rester dans ce forum et demander qu'un responsable le place dans le bon forum ?
  Ouvrir un nouveau fil, dans le forum "Exemples de script" ou "Fonctions et UDF" ?

[jguinch]

Qu'entends-tu par sécuriser les actions entreprises ensuite dans la fenêtre ouverte ?
Sinon pour ton code, s'il est fonctionnel, tu peux le poster dans Exemples de scripts

[Patrick22]

@jguinch
Qu'entends-tu par sécuriser les actions entreprises ensuite dans la fenêtre ouverte ?

Oh, du banal :

• Contrôle existence dossier.
• Contrôle réellement dossier.
• Contrôle pas chemin relatif.
• RegEx sur la classe et le nom du dossier pour couvrir les différents cas d'options d'affichage des dossiers.
• Position et dimensions de la fenêtre paramétrables.
• Renvoi du handle ou de 0 si erreur avec @error valorisé selon les différents cas.

C'est juste "sécurisé", pas "sûr et certain".

Exemples de cas problématique :
- Lancer l'explorateur sur un dossier inexistant excite Windows qui affiche un beau message d'erreur un peu perturbant pour un utilisateur.
- Une fenêtre ouverte sur "C:\" a "(C:) Système" dans le titre. Difficile d'acquérir son handle sur le nom qui a servi a l'ouvrir à moins de modifier Opt("WinTitleMatchMode"). Alors on risque d'obtenir le handle d'une autre fenêtre ouverte contenant aussi ce nom si, pendant l'attente du WinWaitActive(), l'utilisateur ouvre malheureusement une fenêtre différente mais contenant ce nom, "C:\Windows" par exemple.

Quant aux actions, pour l'instant je n'en ai qu'une, positionner sur un raccourci détecté comme étant erroné. Si la fenêtre n'est pas la bonne ce n'est pas du "gros dégât" c'est sûr mais une fois de plus ça induit l'utilisateur en erreur et de toutes façons ça ne fait pas vraiment sérieux d'expliquer ensuite que "oui, heu, c'est parce que la fenêtre était pas la bonne etc."

Mettre ça en fonction évite de re-cogiter sur le code quand on en a besoin, et de re-tester.