[R] DllCall et fenêtres

[milka]

Bonjour à toutes et a tous, je suis un programmeur en herbe, et j'ai deux problèmes que je vais essayer de décrire au maximum.

- Problème N°1 : DllCall :
Tout d'abord, dans mon programme, j'ai besoin d'utiliser des images en arrière plan de fenêtres.
Je l'initialise bien comme ceci :

Code : Tout sélectionner

$Pic1 = GUICtrlCreatePic(@DesktopDir & "\image.jpg", 0, 0, 403, 190, BitOR($SS_NOTIFY,$WS_GROUP,$WS_CLIPSIBLINGS))

C'est bien beau, mais si quelqu'un d'autre que moi l'essaye, soit il ne verra pas l'image, soit je serai obligé de lui envoyer pour qu'il puisse la voir. J'ai donc pensé à intégrer cette image dans une Dll avec le programme de Tlem (que je remercie fortement), mais comment ressortir l'image ?

J'ai trouvé le fonctionnement suivant :

Code : Tout sélectionner

DllCall("dll", "type de retour", "fonction")

Ce qui deverait me donner :

Code : Tout sélectionner

DllCall(@DesktopDir & "\MaDll.dll", "none", "image.jpg")

Mais ceci ne marche pas.

- Problème N°2 : Fonctions, boucles et fenêtres :
En simplifiant beaucoup, j'ai un code similaire à celui là :

► Afficher le texte

Code : Tout sélectionner

#include <ButtonConstants.au3>
#include <ComboConstants.au3>
#include <EditConstants.au3>
#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>
#NoTrayIcon

debut()

Func debut()
    $Form1 = GUICreate("Essai", 363, 158, -1, -1)
    $Button1 = GUICtrlCreateButton("a", 16, 24, 105, 33, $WS_GROUP)
    $Button2 = GUICtrlCreateButton("b", 128, 24, 105, 33, $WS_GROUP)
    $Button3 = GUICtrlCreateButton("c", 240, 24, 105, 33, $WS_GROUP)
    GUISetState(@SW_SHOW)
    While 1
        $nMsg = GUIGetMsg()
        Switch $nMsg
            Case $GUI_EVENT_CLOSE
                Exit
            Case $Button1
                a()
            Case $Button2
                b()
            Case $Button3
                c()
        EndSwitch
    WEnd
EndFunc

Func a()
    $Form1 = GUICreate("a", 403, 190, -1, -1)
    $Button2 = GUICtrlCreateButton("Quitter", 8, 144, 201, 33, $WS_GROUP)
    GUISetState(@SW_SHOW)
    While 1
        $nMsg = GUIGetMsg()
        Switch $nMsg
            Case $GUI_EVENT_CLOSE
                GUIDelete("a")
            Case $Button2
                GUIDelete("a")
        EndSwitch
    WEnd
EndFunc

Func b()
    $Form1 = GUICreate("b", 403, 190, -1, -1)
    $Button2 = GUICtrlCreateButton("Quitter", 8, 144, 201, 33, $WS_GROUP)
    GUISetState(@SW_SHOW)
    While 1
        $nMsg = GUIGetMsg()
        Switch $nMsg
            Case $GUI_EVENT_CLOSE
                GUIDelete("b")
            Case $Button2
                GUIDelete("b")
        EndSwitch
    WEnd
EndFunc

Func c()
    $Form1 = GUICreate("c", 403, 190, -1, -1)
    $Button2 = GUICtrlCreateButton("Quitter", 8, 144, 201, 33, $WS_GROUP)
    GUISetState(@SW_SHOW)
    While 1
        $nMsg = GUIGetMsg()
        Switch $nMsg
            Case $GUI_EVENT_CLOSE
                GUIDelete("c")
            Case $Button2
                GUIDelete("c")
        EndSwitch
    WEnd
EndFunc

Ici, quand je clique sur un bouton a, b ou c; la fenêtre se ferme bien, mais après, la fenêtre essai ne répond plus aux boutons enfoncés.

Si vous pouviez m'éclaircir sur ces deux sujets, ca serait super
Amicalement, milka.

[bloodwolff]

Moi personnellement pour inclure un image dans un .exe, j'utilise cet udf Le problème c'est qu'on ne voit pas l'image si le script n'est pas compilé. Si tu veux un exemple je l'avais utilisé dans ce script

[milka]

Merci pour ta réponse, mais je cherche une méthode d'explication sur DllCall, parce que je préfère trimbaler une dll plutôt que 10 images

[bloodwolff]

Tu n'as pas lu ma réponse attentivement ! Les images sont stocké directement dans le .exe et tu n'as pas à trimbaler ni les images ni les dll, Et si tu tient à les stocker dans une dll ce n'est pas avec dllcall que tu y arrivera

[jchd]

FileInstall() fait exactement ça. Certes l'image n'est pas vue comme une resource, mais cette méthode n'a aucun inconvénient ni incompatibilité connue et restera supportée à l'identique ou mieux dans les futures versions d'AutoIt (il y en aura).

[bloodwolff]

Oui mais on doit installer l'image sur l'ordinateur cible

[jchd]

Un gros FileDelete() si on ne veut pas l'y laisser ne mange pas beaucoup de pain.

[FernandG]

dans les futures versions d'AutoIt (il y en aura).

Peux-tu nous en dire d'avantage ? A quand la prochaine version ? Un apperçu des nouveautés ?

[jchd]

"Quoi" = bogues corrigés et ré-écriture de portions de code interne à AutoIt.
"Qui" = un peu moins de développeurs qu'avant. Rappel : la contribution à AutoIt est volontaire, pas contractuelle et repose donc sur les disponibilités des contributeurs d'UDFs et/ou des développeurs.
"Quand" = mystère.

AutoIt et sa cohorte d'UDFs est raisonnablement utilisable en l'état, mais faire évoluer le coeur demande quelques "réajustements" internes qui ne semblent pas tous triviaux. Un travail bâclé à ce niveau pourrait pénaliser lourdement l'avenir de ce merveilleux produit, donc autant éviter.

En un mot : patience.

[Tlem]

L'utilisation d'une DLL tel que le souhaite milka, n'est pas dénué de bon sens ou d'intérêt.
Imaginez un exécutable qui est correctement développé et compilé et dont on ne souhaite pas exposer ou donner le code source.
Si vous devez modifier une des ressources, vous devez aussi re-compiler l'exécutable, alors que si la ressource est dans une DLL, seule la DLL peut être mise à jour.

Bref, milka, vous trouverez votre bonheur ici : http://www.autoitscript.fr/forum/viewto ... f=11&t=310

[jchd]

Tlem,

Est-ce vrai qu'il n'y a plus d'éditeur-linker de resource capables de travailler avec seulement l'exécutable ?
Il n'y a pas si longtemps, on pouvait changer le contenu (pas la nature ni le nom ou l'index) d'une resource sans recompiler.

[Tlem]

Oui, c'est toujours possible avec ResHacker, mais personnellement je trouve cela moins 'propre'.

Sans compter que ça peut aussi poser des problèmes autres. Sans m'étaler, je prend le cas d'antivirus qui analyse un md5 (ou assimilé) du fichier exécutable et qui bloquerons la nouvelle version.
Ensuite, comment être sure des ressources ajoutées dans tel ou tel
exécutable, puisque la version reste la même (à moins bien sur de se faire chi.. à modifier aussi cela dans les ressources).