Je pense pas qu'elle soit très adaptée au mode console, le plus simple serait d'utiliser les classes Socket, TcpServer ou TcpClient du framework. Qu'est ce que tu veux faire en gros?

Bonjour,

Merci! Et c'est marrant parce qu'en ce moment je suis aussi en train de bosser avec des sockets, mais non bloquants (sous Linux) et avec Python.

Pour être honnête ça fait des années que j'ai pas touché au code et que j'ai pas programmé en VB.NET donc je suis pas sûr d'être d'une grande aide pour trouver le bug.

Mais pour essayer, est ce que les données sont bien envoyées? Est ce que si tu mets un point d'arrêt sur '_socket.Send(data, ...)' dans AutoSocket.Send() il passe dessus? Et sur la ligne 'RaiseEvent DataDeparture' ?

C'est vrai que les classes de Socket de .NET sont pas pratiques à utiliser avec Windows Forms, parce qu'elle ont été pensées pour être utilisée dans une partie client ou serveur de l'application, et non pas mélangée à la présentation (Forms).

Donc d'un côté c'est moins pratique, mais ça force à bien réfléchir à l'architecture de l'application, le flux de données, les threads, etc. Perso c'est quelque chose que j'adore et que je trouve hyper intéressant, mais ça demande pas mal de temps et de recherches.

Par exemple c'est pas une bonne chose d'appeler des fonctions blocantes (synchrones) sur le thread de l'interface graphique, puisque ça fait freezer l'affichage de tes fenêtres. C'est pour ça que le plus simple c'est d'avoir un thread dédié à ton socket. L'alternative c'est d'utiliser les fonctions asynchrones ou des événements mais c'est plus difficile à bien structurer, enfin c'est mon point de vue.

Pas de soucis :)

Ce qui m'étonne un peu c'est que ce bout de code soit toujours utile et utilisé, même 5 ans après que je l'ai écrit !

A+

Xya

Tu peux utiliser n'importe quel contrôle comme SynchronizingObject.

Par exemple imaginons que tu crées le socket dans le constructeur de ta form:

Public Sub New()
   '...
   Me.socket = New AutoSocket()
   Me.socket.SynchronizingObject = Me
End Sub

et après dans tes gestionnaires d'événements t'as plus à te soucier de Invoke/BeginInvoke (cad les événements sont automatiquement exécut´s dans le thread principal):

Private sub Control_Disconnect (sender as Object, e as System.EventArgs) Handles Control.Disconnect
    'Je veu par exemple afficher "déconnecté" dans un label
     label.Text = "Déconnecté"
End sub

L'idé c'est de rajouter une propriété à la classe:

Protected syncObj As ISynchronizeInvoke           'objet de synchronisation Windows Forms

    Public Property SynchronizingObject() As ISynchronizeInvoke
        Get
            Return syncObj
        End Get
        Set(ByVal Value As ISynchronizeInvoke)
            syncObj = Value
        End Set
    End Property

Pour chaque événment tu dois ajouter une méthode OnXXX qui détermine si on doit utiliser BeginInvoke ou pas:

    Public Event Disconnected(ByVal sender As Object, ByVal e As EventArgs)

    Protected Overridable Sub OnDisconnected(ByVal e As EventArgs)
        If Not syncObj Is Nothing AndAlso syncObj.InvokeRequired Then
            Dim deleg As New EventHandler(AddressOf SyncDisconnected)
            syncObj.BeginInvoke(deleg, New Object() {Me, e})
        Else
            SyncDisconnected(sender, e)
        End If
    End Sub

Et une øéthode SyncXXX qui déclenche juste l'événement:

    Protected Sub SyncDisconnected(ByVal sender As Object, ByVal e As EventArgs)
        RaiseEvent Disconnected(sender, e)
    End Sub

La version VB.NET est un peu lourde, comme je pense pas qu'on puisse récupérer le délégué de l'événement contrairement à C#, sinon on pourrait faire (dans OnXXX):

syncObj.BeginInvoke(Me._delegue_Disconnected, New Object() {Me, e})

et se passer de SyncXXX.

Pas de soucis :p J'espère que ca te øettra sur la voie.

Pt'être que pour des raisons de performances cette règle n'est vérifiée que quand tu lance ton programme dans un débogueur comme Visual Studio? De toute qu'elle soit vérifiée ou pas vaut mieux la suivre, ssurtout pour une appli réseau. Je me souviens avoir eu des bugs vraiment bizarre/aléatoires quand je le faisais pas

Si je me souviens bien (j'ai écrit ce code y'a 5 ans quand même :p et pas le courage de le télécharger et de le regarder), le socket doit utiliser un thread d'arrière plan pour gérer les différents événements.

Le problème, c'est que tout les contrôle windows forms (namespace System.Windows.Forms.*) doivent être impérativement utilisés sur le thread principal (c'est à dire tout code qui accède à leur méthodes et propriétés). Il n'y avait aucune vérification dans le Framework 1.1, par contre je crois que c'est à partir du 2.0 que cette "règle est vérifiée", et si elle n'est pas respectée, tu obtiens l'exception que tu as copié-collé.

La solution la plus rapide, c'est d'appeller BeginInvoke/Invoke dans tous les événements du socket, de sorte à exécuter le code qui accède à Windows Forms dans le thread principal. Exemple:

Private Sub socket_DataArrival( sender As Object, data As Byte() )
    Me.BeginInvoke(ma_fonction_windows_forms, New Object[] {data}) ' synatxe VB?
End Sub

Private Sub ma_fonction_windows_forms(data As Byte())
    txtClientInput.Text = Encoding.UTF8.GetString(data)
End Sub

Ca fait des années que j'ai pas fait de VB.NET (et pas de compilateur sous la main), donc je me souviens plus de la syntaxe, surtout pour la création de tableau et le passage du délégué (voir commentaire).
L'idée c'est tu passe un délégué de ta fonction (ici ma_fonction_windows_forms) comme 1er paramètre, et un tableau contenant la liste des paramètres de ta fonction comme 2ième paramètre. Ca c'est la solution rapide, bête et méchante, et pas hyper propre.

La solution plus "clean" serait de rajouter une propriété SynchronizingObject (de type ISrynchronizeInvoke -- interface implémentée par tous les contrôles Windows Forms) à la classe de Socket. Ensuite tu dois utiliser la méthode BeginInvoke de ton objet SynchronizingObject pour déclencher les événements.

Je pense qu'avec ça tu dois avoir pas mal de pistes pour régler le problème (je pense que tu devrais trouver sur le net le code pour utiliser BeginInvoke/Invoke et les événements VB.NET). J'espère que ça t'aidera!

Greetings from Norway
Xya

Salut,

On peut compiler avec NMake des projets VB 2003 (et 2002 également si je me souviens bien) sans que Visual Studio soit installé. Par contre, il faut que le framework .Net 1.1+ soit installé.
Les projets VB 2005 peuvent être compilés sans VS par MSBuild qui est inclus dans le framework .Net 2.0+.

A+

Content de l'entendre :)

Sinon désolé pour les mises à jour multiples, et j'ai également oublié de retirer un fichier qui n'a rien à voir (FileDecrypt.cs).