Discussion :

[louie]

Je suis tombé sur un source qui gère les communication ethernet par l'API wsock32.
Au démarrage de l'appli, une msgbox s'affiche pour dire à l'utilisateur que l'appli utilise le subclassing, donc de ne jamais utiliser le bouton stop du debugger ou utiliser le mot clé End dans le code, sinon le "IDE va crasher".

Quelqu'un connais le subclassing ? Qu'est ce que cela signifie ? Quand il prévient que l'IDE va crasher, il veut dire quoi exactement ?

Si quelqu'un connais les communications par winsocket, y a t'il un moyen de ne pas utiliser le subclassing ?

Merci

[mat.M]

Je suis tombé sur un source qui gère les communication ethernet par l'API wsock32.

Est-ce que tu peux envoyer le source ou bien le publier sur le forum s'il n'est pas long.

A tout hasard je dirais que si cela "crash" c'est parce que cette gestion de communication s'effectue en multithreading ou bien avec un seul Thread

[louie]

Le code dont je parle est celui ci:

http://www.mentalis.org/vbexamples/vbexample.php?vbexample=SERVERCLIENT&category=SOURCE

[mat.M]

salut Louie , tu as de la chance j'ai jeté un coup d'oeil au problème .

Le subclassing qu'est ce que c'est :

Une application VB de base c'est un formulaire une "form".
il faut comprendre ce qui se passe pour une application Windows.
Toute application Windows est un processus ( Thread ).
ce processus reçoit des messages transmis par l'OS ( noyau ? ).
Ainsi lorsque on bouge la souris au-dessus de la fenêtre , celle-ci reçoit le message WM_MOUSEMOVE .
Par exemple , pour exploiter cette événement ou message ( puisque VB c'est programmation événementiel ) , dans l'événement OnMouseMove on placera le code adéquat notamment pour récupérer les coordonnées de la souris ( dessin par ex ).
Lorsqu'on crée une fenêtre donc une "form" , au niveau des méchanismes internes , on parle d'enregistrement de classe de fenêtre ( ne pas confondre avec la notion de classe de POO).
Lors de l'exécution cette classe de fenêtre reçoit dans une file de message un grand nombre de messages ou événements ( comme celui cité précedemment.)
On parle de procédure de traitement des messages

Le SubClassing sert à quoi dans tout cela ??
Eh bien ce méchanisme sert à "détourner" les messages transmis de l'OS à la classe de fenêtre d'application vers un autre procédure de traitement de message ,éventuellement vers la boucle de traitement de message d'un contrôle (EditBox , push button , List Box)
Car un EditBox ( en programmation Windows c'est aussi une classe de fenêtre avec sa file de message.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Public Sub StartSubclass(F As Form)
    PrevProc = SetWindowLong(F.hwnd, GWL_WNDPROC, AddressOf WindowProc)
End Sub

SetWindowLong
The SetWindowLong function changes an attribute of the specified window. The function also sets the 32-bit (long) value at the specified offset into the extra window memory.

On voit ici que SetWindowLong associe la procédure de message initiale à une autre procédure de message

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
Public Function WindowProc(ByVal hwnd As Long, ByVal uMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
    If uMsg = WINSOCK_MESSAGE Then
        ProcessMessage wParam, lParam
    Else
        WindowProc = CallWindowProc(PrevProc, hwnd, uMsg, wParam, lParam)
    End If
End Function

Dans cette nouvelle procédure de message on traite un message particulier envoyé par la classe de fenêtre parente ( grâce à SetWindowLong ), ici concernant les Sockets (WINSOCK_MESSAGE) et traiter les messages attenants :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
Public Function ProcessMessage(ByVal wParam As Long, ByVal lParam As Long) 'wParam = Socket Handle, lParam = connection message
    Select Case lParam
        Case FD_ACCEPT
        Case FD_CONNECT
            MsgBox "Connect"
        Case FD_WRITE
        Case FD_READ
            Dim sTemp As String, lRet As Long, szBuf As String
            Do
                szBuf = String(256, 0)
                lRet = recv(wParam, ByVal szBuf, Len(szBuf), 0)
                If lRet > 0 Then sTemp = sTemp + Left$(szBuf, lRet)
            Loop Until lRet <= 0
            If LenB(sTemp) > 0 Then AddText sTemp
        Case FD_CLOSE
            AddText "Lost connection with server..."
    End Select
End Function

Pour stopper le SubClassing , on prend l'adresse mémoire pointant sur l'ancienne procédure de message, retourné initialement par SetWindowLong.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Public Sub StopSubclass(F As Form)
    If PrevProc <> 0 Then SetWindowLong F.hwnd, GWL_WNDPROC, PrevProc
End Sub

Comme le suggère l'auteur , seuls les messages systèmes sont traités donc suivre les recommendations indiqués.
Les contrôles de la Form ne réagissent plus

y a t'il un moyen de ne pas utiliser le subclassing ?

Oui :
en mettant un timer ( peu fiable ). A chaque manifestation du timer traiter les messages reçus
en utilisant une fonction incorporée dans un "Thread"

[louie]

Merci pour cette explication, ma foi, bien eclaircissante ! (As tu songé as faire un petit tutoriel reprennant cela ?)

Que pense tu être la meilleure solution, le subclassing ou utiliser un thread (ya t'il un tutoriel dessus?) :

Merci encore mat.M

[ado]

Merci pour cette explication, ma foi, bien eclaircissante !

Merci encore mat.M

Mat tu as delivré kelk'un.

[louie]

et délivré est un faible mot...

[mat.M]

(As tu songé as faire un petit tutoriel reprennant cela ?)

j'aimerais bien mais il faudrait que je fasse les 35 heures...par jour

Que pense tu être la meilleure solution, le subclassing ou utiliser un thread (ya t'il un tutoriel dessus?)

Le problème avec les Threads c'est qu'il faut communiquer avec des messages.
Sinon la solution du Timer et d'obtenir les messages systèmes n'est pas mal avec GetMessage.

Mais je pense que la solution du "Subclassing" est la meilleure.
Pour les Threads faire une recherche sur le forum