Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Visual Basic Problème dans la fanction API GetDlgItemText

Problème dans la fanction API GetDlgItemText

14 réponses
Avatar
mml
Bonjour,

Lorsque j'utilise la fonction GetDlgItemText, j'ai le message :

"Point d'entrée de GetDlgItem d'une DLL introuvable dans user32".

alors que la fonction SetDlgItem passe bien.

Je suis en Windows 2000 SP4.

Quelqu'un voit-il la solution ?
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
parci
On Wed, 16 Jan 2008 20:33:08 +0100, "mml" wrote:

Bonjour,

Lorsque j'utilise la fonction GetDlgItemText, j'ai le message :

"Point d'entrée de GetDlgItem d'une DLL introuvable dans user32".

alors que la fonction SetDlgItem passe bien.

Je suis en Windows 2000 SP4.

Quelqu'un voit-il la solution ?



Problème d'alias?

Déclaration pour la version ANSI :
Private Declare Function GetDlgItemText Lib "user32" Alias
"GetDlgItemTextA" (ByVal hDlg As Long, ByVal nIDDlgItem As Long, ByVal
lpString As String, ByVal nMaxCount As Long) As Long

Une alternative : SendMessage avec WM_GETTEXT (c'est que fait
GetDlgItemText)
Avatar
Jean-marc
mml wrote:
Bonjour,

Lorsque j'utilise la fonction GetDlgItemText, j'ai le message :

"Point d'entrée de GetDlgItem d'une DLL introuvable dans user32".

alors que la fonction SetDlgItem passe bien.

Je suis en Windows 2000 SP4.



Hello,

je ne m'en sers pas tous les jours mais ça m'est
arrivé et je ne me rappelle pas de soucis particuliers.

As tu regardé ceci:
http://support.microsoft.com/kb/267939

Il suffit parfois d'une simple erreur d'inattention dans
le Declare pour avoir ensuite ce genre de messages d'erreur.

Bon débuggage;

Cordialement,

--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
Avatar
mml
Merci de cette réponse.

En effet, problème d'alias. Merci beaucoup.

"parci" a écrit dans le message de
news:
On Wed, 16 Jan 2008 20:33:08 +0100, "mml" wrote:

>Bonjour,
>
>Lorsque j'utilise la fonction GetDlgItemText, j'ai le message :
>
>"Point d'entrée de GetDlgItem d'une DLL introuvable dans user32".
>
>alors que la fonction SetDlgItem passe bien.
>
>Je suis en Windows 2000 SP4.
>
>Quelqu'un voit-il la solution ?

Problème d'alias?

Déclaration pour la version ANSI :
Private Declare Function GetDlgItemText Lib "user32" Alias
"GetDlgItemTextA" (ByVal hDlg As Long, ByVal nIDDlgItem As Long, ByVal
lpString As String, ByVal nMaxCount As Long) As Long

Une alternative : SendMessage avec WM_GETTEXT (c'est que fait
GetDlgItemText)



Avatar
mml
OK, merci.


"Jean-marc" a écrit dans le message
de news:478e6202$0$29265$
mml wrote:
> Bonjour,
>
> Lorsque j'utilise la fonction GetDlgItemText, j'ai le message :
>
> "Point d'entrée de GetDlgItem d'une DLL introuvable dans user32".
>
> alors que la fonction SetDlgItem passe bien.
>
> Je suis en Windows 2000 SP4.

Hello,

je ne m'en sers pas tous les jours mais ça m'est
arrivé et je ne me rappelle pas de soucis particuliers.

As tu regardé ceci:
http://support.microsoft.com/kb/267939

Il suffit parfois d'une simple erreur d'inattention dans
le Declare pour avoir ensuite ce genre de messages d'erreur.

Bon débuggage;

Cordialement,

--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;






Avatar
mml
D'autre part, pourrai-je avoir un bout de code illustrant la méthode
utilisant SendMessage avec WM_GETTEXT, stp ?


"parci" a écrit dans le message de
news:
On Wed, 16 Jan 2008 20:33:08 +0100, "mml" wrote:

>Bonjour,
>
>Lorsque j'utilise la fonction GetDlgItemText, j'ai le message :
>
>"Point d'entrée de GetDlgItem d'une DLL introuvable dans user32".
>
>alors que la fonction SetDlgItem passe bien.
>
>Je suis en Windows 2000 SP4.
>
>Quelqu'un voit-il la solution ?

Problème d'alias?

Déclaration pour la version ANSI :
Private Declare Function GetDlgItemText Lib "user32" Alias
"GetDlgItemTextA" (ByVal hDlg As Long, ByVal nIDDlgItem As Long, ByVal
lpString As String, ByVal nMaxCount As Long) As Long

Une alternative : SendMessage avec WM_GETTEXT (c'est que fait
GetDlgItemText)



Avatar
Jean-marc
mml wrote:
D'autre part, pourrai-je avoir un bout de code illustrant la méthode
utilisant SendMessage avec WM_GETTEXT, stp ?



Hello,

voici un petit bout de code.
Il te faut une form, un textbox et un bouton de commande.

tu tapes qq chose dans la textbox puis tu cliques sur
le bouton.

Option Explicit

Private Declare Function SendMessage Lib "USER32" Alias "SendMessageA" ( _
ByVal hWnd As Long, ByVal Msg As Long, _
wParam As Any, lParam As Any) As Long

Const WM_GETTEXT As Long = &HD

Private Sub Form_Load()

Text1.PasswordChar = "*"
End Sub

Private Sub Command1_Click()

Dim res As Long
Dim buf As String

buf = Space(255)
res = SendMessage(Text1.hWnd, WM_GETTEXT, ByVal 255&, ByVal StrPtr(buf))
buf = StrConv(buf, vbUnicode)
MsgBox "buf = " & buf

End Sub

C'est comme ça que marchent les "révélateurs" de mots de passe ...

Cordialement;

--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
Avatar
parci
On Wed, 16 Jan 2008 22:31:56 +0100, "Jean-marc"
wrote:

Option Explicit

Private Declare Function SendMessage Lib "USER32" Alias "SendMessageA" ( _
ByVal hWnd As Long, ByVal Msg As Long, _
wParam As Any, lParam As Any) As Long

Const WM_GETTEXT As Long = &HD

Private Sub Form_Load()

Text1.PasswordChar = "*"
End Sub

Private Sub Command1_Click()

Dim res As Long
Dim buf As String

buf = Space(255)
res = SendMessage(Text1.hWnd, WM_GETTEXT, ByVal 255&, ByVal StrPtr(buf))
buf = StrConv(buf, vbUnicode)
MsgBox "buf = " & buf

End Sub



Par curiosité, Jean Marc,

est-ce qu'il y a une raison particluière à utiliser StrPtr dans ce cas
? Je l'aurais plutôt écrit comme ça :

res = SendMessage(Text1.hWnd, WM_GETTEXT, ByVal 255&, ByVal buf)
If res Then
MsgBox "buf = " & Left$(buf, res)
End If
Avatar
Jean-marc
parci wrote:
On Wed, 16 Jan 2008 22:31:56 +0100, "Jean-marc"
wrote:
Par curiosité, Jean Marc,

est-ce qu'il y a une raison particluière à utiliser StrPtr dans ce cas
? Je l'aurais plutôt écrit comme ça :

res = SendMessage(Text1.hWnd, WM_GETTEXT, ByVal 255&, ByVal buf)
If res Then
MsgBox "buf = " & Left$(buf, res)
End If



Hello Parci,

(( FRANCOIS, si tu nous lis ?? ))

On peut effectivement faire comme tu dis, ça fonctionnera très bien
et économiseras un appel à StrConv(), ce qui est bien !

Le test if res=0 n'est pas utile, on a en effet un res=0 légitime
si la textbox est vide, et Left() ne se plaindra pas dans ce cas.

On pourrait aussi écrire:

buf = Space(255)
res = SendMessage(Text1.hWnd, WM_GETTEXT, ByVal 255&, ByVal buf)
buf = Mid$(buf, 1, InStr(buf, vbNullChar) - 1)

En pratique, je pense que les 2 méthodes (Byval et StrPtr) sont
correctes, avec sans doute un avantage à ta méthode qui évite
le StrConv.

J'aimerais avoir l'avis de François, s'il nous lit ???

a+


--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
Avatar
François Picalausa
On Jan 17, 9:46 pm, "Jean-marc"
wrote:
parci wrote:
> On Wed, 16 Jan 2008 22:31:56 +0100, "Jean-marc"
> wrote:
> Par curiosité, Jean Marc,

> est-ce qu'il y a une raison particluière à utiliser StrPtr dans ce c as
> ? Je l'aurais plutôt écrit comme ça :

>    res = SendMessage(Text1.hWnd, WM_GETTEXT, ByVal 255&, ByVal buf )
>    If res Then
>        MsgBox "buf = " & Left$(buf, res)
>    End If

Hello Parci,

  (( FRANCOIS, si tu nous lis ?? ))

On peut effectivement faire comme tu dis, ça fonctionnera très bien
et économiseras un appel à StrConv(), ce qui est bien !

Le test if res=0 n'est pas utile, on a en effet un res=0 légitime
si la textbox est vide, et Left() ne se plaindra pas dans ce cas.

On pourrait aussi écrire:

    buf = Space(255)
    res = SendMessage(Text1.hWnd, WM_GETTEXT, ByVal 255&, ByVal buf)
    buf = Mid$(buf, 1, InStr(buf, vbNullChar) - 1)

En pratique, je pense que les 2 méthodes (Byval et StrPtr) sont
correctes, avec sans doute un avantage à ta méthode qui évite
le StrConv.

J'aimerais avoir l'avis de François, s'il nous lit ???



Hello,

Ton analyse est plus ou moins correcte.
En effet, le passage de buffer byval
SendMessage(Text1.hWnd, WM_GETTEXT, ByVal 255&, ByVal buf)
entrainera 2 "StrConv" : un en entrée, et un en sortie; une chaine
temporaire est aussi créée dans ce processus. Tout ça est fait de
manière transparente.

Il vaudrait donc mieux utiliser la méthode avec StrPtr et StrConv (un
benchmark devrait être réalisé pour s'en assurer formellement), sauf
que
<quote src="http://support.microsoft.com/kb/199824">
WARNING: One or more of the following functions are discussed in this
article; VarPtr, VarPtrArray, VarPtrStringArray, StrPtr, ObjPtr. These
functions are not supported by Microsoft Technical Support. They are
not documented in the Visual Basic documentation and are provided in
this Knowledge Base article "as is."
</quote>

Cela étant, si le support d'unicode par MSLU sur 9x est acceptable (ou
que 9x ne doit pas être supporté), on peut travailler directement en
unicode:
Private Declare Function SendMessage Lib "USER32" Alias
"SendMessageW" ( _
ByVal hWnd As Long, ByVal Msg As Long, _
wParam As Any, lParam As Any) As Long

buf = Space(255)
res = SendMessage(Text1.hWnd, WM_GETTEXT, ByVal 255&, ByVal
StrPtr(buf))
MsgBox "buf = " & left$(buf , res)

On évite toute conversion, donc ça va encore plus vite.

Cela étant, c'est probablement le seul avantage. Et pour manipuler de
l'UI, on en est généralement pas à un temps de conversion près. Donc
mon avis personnel serait, dans ce cas ci, de laisser VB faire en
utilisant:
SendMessage(Text1.hWnd, WM_GETTEXT, ByVal 255&, ByVal buf)
parce que cette syntaxe est documenté et a (probablement) été
nettement plus testée que celle utilisant StrPtr.

Néanmoins, on peut facilement imaginer d'autres cas où la performance
importe, et où passer directement la chaine en unicode (et
éventuellement réaliser les conversions spécifiques avant ou après e n
fonction du cas) apporte de nettes améliorations. Notament, il me
semble me souvenir que le triplet FindFirstFile/FindNextFile/FindClose
est plus performant dans sa version W, lors d'appels depuis VB. Je ne
sais pas si c'est imputable à la conversion que fait VB, ou si
l'implémentation de la version A est le réel point problématique, mais
ça montre certainement le point que certains appels à la version W
avec StrPtr peuvent être plus intéressants.

Sur le plan de l'utilisation de WM_GETTEXT par contre, pour que
l'exemple soit complet il faudrait un appel complémentaire à
WM_GETTEXTLENGTH:
<quote src="Windows SDK">
Under certain conditions, the DefWindowProc function returns a value
that is larger than the actual length of the text. This occurs with
certain mixtures of ANSI and Unicode, and is due to the system
allowing for the possible existence of double-byte character set
(DBCS) characters within the text. The return value, however, will
always be at least as large as the actual length of the text; you can
thus always use it to guide buffer allocation.
</quote>

Const WM_GETTEXTLENGTH As Long = &h000E

buf = Space(SendMessage(Text1.hWnd, WM_GETTEXTLENGTH, ByVal 0&,
ByVal 0&))
If Lenb(buf) Then
res = SendMessage(Text1.hWnd, WM_GETTEXT, ByVal 255&, ByVal
StrPtr(buf))
MsgBox "buf = " & left$(buf , res)
End If

François
Avatar
Jean-marc
>François Picalausa wrote:



<snip les immenses précisions>

Je me disais bien que tu aurais en réserve une jolie explication
extrèmement documentée, mais je n'en espérais quand même
pas tant :-)))))))))

A++


--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
1 2