[]Subclassing

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

Citation:

---

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

Le code dont je parle est celui ci:

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

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

Le subclassing qu'est ce que c'est :

:arrow: Une application VB de base c'est un formulaire une "form".
:arrow: 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:

---

1 2 3 4

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

---

Citation:

---

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:

---

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:

---

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:

---

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

Citation:

---

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

---

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

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

Citation:

---

Envoyé par louie

Merci pour cette explication, ma foi, bien eclaircissante !

Merci encore mat.M

---

Mat tu as delivré kelk'un. http://www.freegaia.com/smileys/img_src/saut21.gif

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

Citation:

---

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

---

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

Citation:

---

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