un truc bizarre avec l'API PostMessage et FindWindow
l'API-Guide donne à peu près ceci :
Dim WinWnd As Long, Ret As String, RetVal As Long, lpClassName As String
'Search the window
WinWnd = FindWindow(vbNullString, Ret)
If WinWnd = 0 Then
MsgBox "Couldn't find the window ..."
Else
MsgBox WinWnd
End If
'Show the window
ShowWindow WinWnd, SW_SHOWNORMAL
'Create a buffer
lpClassName = Space(256)
PostMessage WinWnd, WM_CLOSE, 0&, 0&
(j'ai rajouté le msgbox WinWnd pour être certain que mon problème était pas
lié à la détection de la fenêtre)
or, je détecte bien la fenêtre que je veux fermer, mais le postmessage ne
fonctionne pas ??
il me semble que c'est la valeur de WinWND qui est pas correcte ...
(ou ce que je souhaite faire n'est pas bon !)
si je récupère le handle de la fenêtre avec Window Analyser, et que je
remplace WinWnd par cette valeur, là, ça fonctionne !!
bref, je pateauge ....
--
Attention ! Adresse mail invalide ...
Pour me contacter, cliquez sur le lien ci-dessous:
http://scraper.chez.tiscali.fr/contact.htm
Il me semble que wm_Close est une demande de fermeture de l'application par l'utilisateur (= Fichier|Quitter ou X sur fenêtre),
WM_CLOSE est une demande de fermeture de fenêtre ou de l'application, que ce soit par le code, par Windows ou par l'utilisateur. http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowmessages/wm_close.asp
alors que wm_Destroy est une commande de fermeture de l'application.
DestroyWindow ne fait déchager une fenêtre (et ses ressources) de la mémoire, c'est l'équivalent de la méthode Unload() de VB. http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowfunctions/destroywindow.asp
Donc un wm_Close sur un Word avec un doc non enregistré va entraîner une boîte de dialogue "Voulez-vous enregistrer ?".
Exact. C'est l'application qui, lorsqu'elle reçoit le WM_CLOSE, exécute le code de sortie et donc permet la sauvegarde de l'usager. Une fois la réponse donnée, l'application continue de s'éteindre. Tandis que DestroyWindow dans la même situation ne fera rien du tout étant donnée que Word fonctionne dans un processus qui lui est propre et donc pas dans le même thread que l'application appelant DestroyWindow() ...
Il me semble que wm_Close est une demande de fermeture de l'application
par l'utilisateur (= Fichier|Quitter ou X sur fenêtre),
WM_CLOSE est une demande de fermeture de fenêtre ou de l'application, que ce
soit par le code, par Windows ou par l'utilisateur.
http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowmessages/wm_close.asp
alors que
wm_Destroy est une commande de fermeture de l'application.
DestroyWindow ne fait déchager une fenêtre (et ses ressources) de la
mémoire, c'est l'équivalent de la méthode Unload() de VB.
http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowfunctions/destroywindow.asp
Donc un wm_Close sur un Word avec un doc non enregistré va entraîner une
boîte de dialogue "Voulez-vous enregistrer ?".
Exact. C'est l'application qui, lorsqu'elle reçoit le WM_CLOSE, exécute le
code de sortie et donc permet la sauvegarde de l'usager. Une fois la réponse
donnée, l'application continue de s'éteindre. Tandis que DestroyWindow dans
la même situation ne fera rien du tout étant donnée que Word fonctionne dans
un processus qui lui est propre et donc pas dans le même thread que
l'application appelant DestroyWindow() ...
Il me semble que wm_Close est une demande de fermeture de l'application par l'utilisateur (= Fichier|Quitter ou X sur fenêtre),
WM_CLOSE est une demande de fermeture de fenêtre ou de l'application, que ce soit par le code, par Windows ou par l'utilisateur. http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowmessages/wm_close.asp
alors que wm_Destroy est une commande de fermeture de l'application.
DestroyWindow ne fait déchager une fenêtre (et ses ressources) de la mémoire, c'est l'équivalent de la méthode Unload() de VB. http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowfunctions/destroywindow.asp
Donc un wm_Close sur un Word avec un doc non enregistré va entraîner une boîte de dialogue "Voulez-vous enregistrer ?".
Exact. C'est l'application qui, lorsqu'elle reçoit le WM_CLOSE, exécute le code de sortie et donc permet la sauvegarde de l'usager. Une fois la réponse donnée, l'application continue de s'éteindre. Tandis que DestroyWindow dans la même situation ne fera rien du tout étant donnée que Word fonctionne dans un processus qui lui est propre et donc pas dans le même thread que l'application appelant DestroyWindow() ...
> > Pour lister les windows, il existe l'API EnumWindows.
Yep. D'ailleurs la doc précise que cette méthode est plus fiable que GetWindow() dans une boucle :
"This function is more reliable than calling the GetWindow function in a loop. An application that calls GetWindow to perform this task risks being caught in an infinite loop or referencing a handle to a window that has been destroyed. "
- MSDN
ah oui .. j'avais pas réussi à la mettre en oeuvre .... (humm .... le
adress
of, j'ai encore pas compris ...)
EnumWindows AddressOf CloseOEProc, ByVal 0&
La méthode EnumWindows() utilise un technique appellée callback. La fonction EnumWindows() appelle la fonction contenu à l'adresse spécifié dans son paramètre lpEnumFunc et l'opérateur AddressOf de VB permet de retourner l'addresse d'une fonction. Dans le code ci-haut tu passes l'adresse de la fonction CloseOEProc(), c'est donc cette fonction qui sera appelée au besoin par EnumWindows().
> > Pour lister les windows, il existe l'API EnumWindows.
Yep. D'ailleurs la doc précise que cette méthode est plus fiable que
GetWindow() dans une boucle :
"This function is more reliable than calling the GetWindow
function in a loop. An application that calls GetWindow to
perform this task risks being caught in an infinite loop or
referencing a handle to a window that has been destroyed. "
- MSDN
ah oui .. j'avais pas réussi à la mettre en oeuvre .... (humm .... le
adress
of, j'ai encore pas compris ...)
EnumWindows AddressOf CloseOEProc, ByVal 0&
La méthode EnumWindows() utilise un technique appellée callback. La fonction
EnumWindows() appelle la fonction contenu à l'adresse spécifié dans son
paramètre lpEnumFunc et l'opérateur AddressOf de VB permet de retourner
l'addresse d'une fonction. Dans le code ci-haut tu passes l'adresse de la
fonction CloseOEProc(), c'est donc cette fonction qui sera appelée au besoin
par EnumWindows().
> > Pour lister les windows, il existe l'API EnumWindows.
Yep. D'ailleurs la doc précise que cette méthode est plus fiable que GetWindow() dans une boucle :
"This function is more reliable than calling the GetWindow function in a loop. An application that calls GetWindow to perform this task risks being caught in an infinite loop or referencing a handle to a window that has been destroyed. "
- MSDN
ah oui .. j'avais pas réussi à la mettre en oeuvre .... (humm .... le
adress
of, j'ai encore pas compris ...)
EnumWindows AddressOf CloseOEProc, ByVal 0&
La méthode EnumWindows() utilise un technique appellée callback. La fonction EnumWindows() appelle la fonction contenu à l'adresse spécifié dans son paramètre lpEnumFunc et l'opérateur AddressOf de VB permet de retourner l'addresse d'une fonction. Dans le code ci-haut tu passes l'adresse de la fonction CloseOEProc(), c'est donc cette fonction qui sera appelée au besoin par EnumWindows().
Salut à François Picalausa qui dans son post news:% nous a écrit/répondu :
Hello,
Pour lister les windows, il existe l'API EnumWindows.
ah oui .. j'avais pas réussi à la mettre en oeuvre .... (humm .... le adress of, j'ai encore pas compris ...)
Supposons qu'on veuille appeler une procédure distante pour demande des informations supplémentaires. En VB, comme on ne connait pas le nom de la procédure puisqu'on ne l'a pas créée, ni l'objet qui possède cette procédure on apelle CallByName. Avec les API c'est la même chose! La différence c'est qu'une API Windows ne parle pas en termes de nom de procédure et d'objet (enfin.. dans une optique COM uniquement ça pourrait se faire... la preuve c'est CallByName), mais ces API parlent plutôt en terme d'adresse en mémoire (pointeur) où se trouve la fonction. En VB, parler de pointeur c'est quasiment de l'hérésie, voila pourquoi on a l'opérateur AddressOf qui permet d'avoir un pointeur sans savoir que c'en est un. Une fois que l'API a l'adresse, elle peut l'apeller...
'----- Dim sSave As String, Ret As Long Ret = GetWindowTextLength(hwnd) sSave = Space(Ret)
GetWindowText hwnd, sSave, Ret + 1 voila, je pense pas avoir commis de grossière erreur en adaptant ??
Juste une question, pourquoi récupérer le titre de la fenêtre (GetWindowText), si tu ne t'en sert pas? ou alors j'ai mal comprenu ;-)
-- François Picalausa (MVP VB) http://faq.vb.free.fr --- http://msdn.microsoft.com http://apisvb.europe.webmatrixhosting.net
Hello,
"scraper" <scraper@pasdespam.fr> a écrit dans le message de
news:eODvu$xbEHA.996@TK2MSFTNGP12.phx.gbl
Salut à François Picalausa qui dans son post
news:%23x8f8QwbEHA.796@TK2MSFTNGP09.phx.gbl
nous a écrit/répondu :
Hello,
Pour lister les windows, il existe l'API EnumWindows.
ah oui .. j'avais pas réussi à la mettre en oeuvre .... (humm .... le
adress of, j'ai encore pas compris ...)
Supposons qu'on veuille appeler une procédure distante pour demande des
informations supplémentaires. En VB, comme on ne connait pas le nom de la
procédure puisqu'on ne l'a pas créée, ni l'objet qui possède cette procédure
on apelle CallByName.
Avec les API c'est la même chose! La différence c'est qu'une API Windows ne
parle pas en termes de nom de procédure et d'objet (enfin.. dans une optique
COM uniquement ça pourrait se faire... la preuve c'est CallByName), mais ces
API parlent plutôt en terme d'adresse en mémoire (pointeur) où se trouve la
fonction. En VB, parler de pointeur c'est quasiment de l'hérésie, voila
pourquoi on a l'opérateur AddressOf qui permet d'avoir un pointeur sans
savoir que c'en est un. Une fois que l'API a l'adresse, elle peut
l'apeller...
'-----
Dim sSave As String, Ret As Long
Ret = GetWindowTextLength(hwnd)
sSave = Space(Ret)
GetWindowText hwnd, sSave, Ret + 1
voila, je pense pas avoir commis de grossière erreur en adaptant ??
Juste une question, pourquoi récupérer le titre de la fenêtre
(GetWindowText), si tu ne t'en sert pas?
ou alors j'ai mal comprenu ;-)
--
François Picalausa (MVP VB)
http://faq.vb.free.fr --- http://msdn.microsoft.com
http://apisvb.europe.webmatrixhosting.net
Salut à François Picalausa qui dans son post news:% nous a écrit/répondu :
Hello,
Pour lister les windows, il existe l'API EnumWindows.
ah oui .. j'avais pas réussi à la mettre en oeuvre .... (humm .... le adress of, j'ai encore pas compris ...)
Supposons qu'on veuille appeler une procédure distante pour demande des informations supplémentaires. En VB, comme on ne connait pas le nom de la procédure puisqu'on ne l'a pas créée, ni l'objet qui possède cette procédure on apelle CallByName. Avec les API c'est la même chose! La différence c'est qu'une API Windows ne parle pas en termes de nom de procédure et d'objet (enfin.. dans une optique COM uniquement ça pourrait se faire... la preuve c'est CallByName), mais ces API parlent plutôt en terme d'adresse en mémoire (pointeur) où se trouve la fonction. En VB, parler de pointeur c'est quasiment de l'hérésie, voila pourquoi on a l'opérateur AddressOf qui permet d'avoir un pointeur sans savoir que c'en est un. Une fois que l'API a l'adresse, elle peut l'apeller...
'----- Dim sSave As String, Ret As Long Ret = GetWindowTextLength(hwnd) sSave = Space(Ret)
GetWindowText hwnd, sSave, Ret + 1 voila, je pense pas avoir commis de grossière erreur en adaptant ??
Juste une question, pourquoi récupérer le titre de la fenêtre (GetWindowText), si tu ne t'en sert pas? ou alors j'ai mal comprenu ;-)
-- François Picalausa (MVP VB) http://faq.vb.free.fr --- http://msdn.microsoft.com http://apisvb.europe.webmatrixhosting.net
Stéphane Santon
Bonjour,
Zoury a écrit :
Tandis que DestroyWindow dans la même situation ne fera rien du tout étant donnée que Word fonctionne dans un processus qui lui est propre et donc pas dans le même thread que l'application appelant DestroyWindow() ...
Très juste. Big difference. Je n'avais plus cette nuance en tête.
-- ** Anti-Spam : ajouter [usenet] dans l'objet pour ne pas être rejeté.
Cordialement, Stéphane *** http://www.team-santonum.com Loisirs, nature, arts, technologie : accueil en Charente-Maritime
Bonjour,
Zoury a écrit :
Tandis que DestroyWindow dans
la même situation ne fera rien du tout étant donnée que Word fonctionne dans
un processus qui lui est propre et donc pas dans le même thread que
l'application appelant DestroyWindow() ...
Très juste. Big difference.
Je n'avais plus cette nuance en tête.
--
** Anti-Spam : ajouter [usenet] dans l'objet pour ne pas être rejeté.
Cordialement, Stéphane *** http://www.team-santonum.com
Loisirs, nature, arts, technologie : accueil en Charente-Maritime
Tandis que DestroyWindow dans la même situation ne fera rien du tout étant donnée que Word fonctionne dans un processus qui lui est propre et donc pas dans le même thread que l'application appelant DestroyWindow() ...
Très juste. Big difference. Je n'avais plus cette nuance en tête.
-- ** Anti-Spam : ajouter [usenet] dans l'objet pour ne pas être rejeté.
Cordialement, Stéphane *** http://www.team-santonum.com Loisirs, nature, arts, technologie : accueil en Charente-Maritime
scraper
Salut à Zoury qui dans son post news: nous a écrit/répondu :
Yep. D'ailleurs la doc précise que cette méthode est plus fiable que GetWindow() dans une boucle :
"This function is more reliable than calling the GetWindow function in a loop. An application that calls GetWindow to perform this task risks being caught in an infinite loop or referencing a handle to a window that has been destroyed. "
- MSDN
oK, merci pour les précisions :-)
La méthode EnumWindows() utilise un technique appellée callback. La fonction EnumWindows() appelle la fonction contenu à l'adresse spécifié dans son paramètre lpEnumFunc et l'opérateur AddressOf de VB permet de retourner l'addresse d'une fonction. Dans le code ci-haut tu passes l'adresse de la fonction CloseOEProc(), c'est donc cette fonction qui sera appelée au besoin par EnumWindows().
voui ... tout ça est assez nébuleux pour moi, je l'avoue !
je vais essayer de regarder dans l'aide si je comprends quelque chose à leurs explications ?
merci en tout cas
--
Attention ! Adresse mail invalide ... Pour me contacter, cliquez sur le lien ci-dessous: http://scraper.chez.tiscali.fr/contact.htm
scraper
Salut à Zoury qui dans son post
news:er93lfybEHA.3864@TK2MSFTNGP10.phx.gbl
nous a écrit/répondu :
Yep. D'ailleurs la doc précise que cette méthode est plus fiable que
GetWindow() dans une boucle :
"This function is more reliable than calling the GetWindow
function in a loop. An application that calls GetWindow to
perform this task risks being caught in an infinite loop or
referencing a handle to a window that has been destroyed. "
- MSDN
oK, merci pour les précisions :-)
La méthode EnumWindows() utilise un technique appellée callback. La
fonction EnumWindows() appelle la fonction contenu à l'adresse
spécifié dans son paramètre lpEnumFunc et l'opérateur AddressOf de VB
permet de retourner l'addresse d'une fonction. Dans le code ci-haut
tu passes l'adresse de la fonction CloseOEProc(), c'est donc cette
fonction qui sera appelée au besoin par EnumWindows().
voui ... tout ça est assez nébuleux pour moi, je l'avoue !
je vais essayer de regarder dans l'aide si je comprends quelque chose à
leurs explications ?
merci en tout cas
--
Attention ! Adresse mail invalide ...
Pour me contacter, cliquez sur le lien ci-dessous:
http://scraper.chez.tiscali.fr/contact.htm
Salut à Zoury qui dans son post news: nous a écrit/répondu :
Yep. D'ailleurs la doc précise que cette méthode est plus fiable que GetWindow() dans une boucle :
"This function is more reliable than calling the GetWindow function in a loop. An application that calls GetWindow to perform this task risks being caught in an infinite loop or referencing a handle to a window that has been destroyed. "
- MSDN
oK, merci pour les précisions :-)
La méthode EnumWindows() utilise un technique appellée callback. La fonction EnumWindows() appelle la fonction contenu à l'adresse spécifié dans son paramètre lpEnumFunc et l'opérateur AddressOf de VB permet de retourner l'addresse d'une fonction. Dans le code ci-haut tu passes l'adresse de la fonction CloseOEProc(), c'est donc cette fonction qui sera appelée au besoin par EnumWindows().
voui ... tout ça est assez nébuleux pour moi, je l'avoue !
je vais essayer de regarder dans l'aide si je comprends quelque chose à leurs explications ?
merci en tout cas
--
Attention ! Adresse mail invalide ... Pour me contacter, cliquez sur le lien ci-dessous: http://scraper.chez.tiscali.fr/contact.htm
scraper
scraper
Salut à François Picalausa qui dans son post news:%23H% nous a écrit/répondu :
Supposons qu'on veuille appeler une procédure distante pour demande des informations supplémentaires. En VB, comme on ne connait pas le nom de la procédure puisqu'on ne l'a pas créée, ni l'objet qui possède cette procédure on apelle CallByName. Avec les API c'est la même chose! La différence c'est qu'une API Windows ne parle pas en termes de nom de procédure et d'objet (enfin.. dans une optique COM uniquement ça pourrait se faire... la preuve c'est CallByName), mais ces API parlent plutôt en terme d'adresse en mémoire (pointeur) où se trouve la fonction. En VB, parler de pointeur c'est quasiment de l'hérésie, voila pourquoi on a l'opérateur AddressOf qui permet d'avoir un pointeur sans savoir que c'en est un. Une fois que l'API a l'adresse, elle peut l'apeller...
oops ! n'en jette plus, j'ai décroché ... :-(
je vais essayer de trouver de la doc, parce que là, c'est fort embrouillé ....
'----- Dim sSave As String, Ret As Long Ret = GetWindowTextLength(hwnd) sSave = Space(Ret)
GetWindowText hwnd, sSave, Ret + 1 voila, je pense pas avoir commis de grossière erreur en adaptant ??
Juste une question, pourquoi récupérer le titre de la fenêtre (GetWindowText), si tu ne t'en sert pas? ou alors j'ai mal comprenu ;-)
c'est ma foi vrai ... je m'imaginais que j'avais besoin de ça pour récupérer les infos sur la fenêtre, et il aparait que EnumWindow fait tout toute seule :-) merci encore
--
Attention ! Adresse mail invalide ... Pour me contacter, cliquez sur le lien ci-dessous: http://scraper.chez.tiscali.fr/contact.htm
scraper
Salut à François Picalausa qui dans son post
news:%23H%23vInybEHA.216@TK2MSFTNGP10.phx.gbl
nous a écrit/répondu :
Supposons qu'on veuille appeler une procédure distante pour demande
des informations supplémentaires. En VB, comme on ne connait pas le
nom de la procédure puisqu'on ne l'a pas créée, ni l'objet qui
possède cette procédure on apelle CallByName.
Avec les API c'est la même chose! La différence c'est qu'une API
Windows ne parle pas en termes de nom de procédure et d'objet
(enfin.. dans une optique COM uniquement ça pourrait se faire... la
preuve c'est CallByName), mais ces API parlent plutôt en terme
d'adresse en mémoire (pointeur) où se trouve la fonction. En VB,
parler de pointeur c'est quasiment de l'hérésie, voila pourquoi on a
l'opérateur AddressOf qui permet d'avoir un pointeur sans savoir que
c'en est un. Une fois que l'API a l'adresse, elle peut l'apeller...
oops !
n'en jette plus, j'ai décroché ... :-(
je vais essayer de trouver de la doc, parce que là, c'est fort embrouillé
....
'-----
Dim sSave As String, Ret As Long
Ret = GetWindowTextLength(hwnd)
sSave = Space(Ret)
GetWindowText hwnd, sSave, Ret + 1
voila, je pense pas avoir commis de grossière erreur en adaptant ??
Juste une question, pourquoi récupérer le titre de la fenêtre
(GetWindowText), si tu ne t'en sert pas?
ou alors j'ai mal comprenu ;-)
c'est ma foi vrai ... je m'imaginais que j'avais besoin de ça pour récupérer
les infos sur la fenêtre, et il aparait que EnumWindow fait tout toute seule
:-)
merci encore
--
Attention ! Adresse mail invalide ...
Pour me contacter, cliquez sur le lien ci-dessous:
http://scraper.chez.tiscali.fr/contact.htm
Salut à François Picalausa qui dans son post news:%23H% nous a écrit/répondu :
Supposons qu'on veuille appeler une procédure distante pour demande des informations supplémentaires. En VB, comme on ne connait pas le nom de la procédure puisqu'on ne l'a pas créée, ni l'objet qui possède cette procédure on apelle CallByName. Avec les API c'est la même chose! La différence c'est qu'une API Windows ne parle pas en termes de nom de procédure et d'objet (enfin.. dans une optique COM uniquement ça pourrait se faire... la preuve c'est CallByName), mais ces API parlent plutôt en terme d'adresse en mémoire (pointeur) où se trouve la fonction. En VB, parler de pointeur c'est quasiment de l'hérésie, voila pourquoi on a l'opérateur AddressOf qui permet d'avoir un pointeur sans savoir que c'en est un. Une fois que l'API a l'adresse, elle peut l'apeller...
oops ! n'en jette plus, j'ai décroché ... :-(
je vais essayer de trouver de la doc, parce que là, c'est fort embrouillé ....
'----- Dim sSave As String, Ret As Long Ret = GetWindowTextLength(hwnd) sSave = Space(Ret)
GetWindowText hwnd, sSave, Ret + 1 voila, je pense pas avoir commis de grossière erreur en adaptant ??
Juste une question, pourquoi récupérer le titre de la fenêtre (GetWindowText), si tu ne t'en sert pas? ou alors j'ai mal comprenu ;-)
c'est ma foi vrai ... je m'imaginais que j'avais besoin de ça pour récupérer les infos sur la fenêtre, et il aparait que EnumWindow fait tout toute seule :-) merci encore
--
Attention ! Adresse mail invalide ... Pour me contacter, cliquez sur le lien ci-dessous: http://scraper.chez.tiscali.fr/contact.htm
