UTILISATION DE WINSOCK POUR VB.NET

Messages postés
1491
Date d'inscription
dimanche 19 novembre 2000
Statut
Modérateur
Dernière intervention
7 juillet 2014
- - Dernière réponse : TeBeCo
Messages postés
467
Date d'inscription
lundi 24 juin 2002
Statut
Membre
Dernière intervention
9 mars 2011
- 19 avril 2010 à 01:03
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/30151-utilisation-de-winsock-pour-vb-net

Afficher la suite 
cs_max12
Messages postés
1491
Date d'inscription
dimanche 19 novembre 2000
Statut
Modérateur
Dernière intervention
7 juillet 2014
-
Corrige ta petite faute dans le titre pour qu'il soit plus facile à trouver par le moteur de recherche :)
cs_Crazyht
Messages postés
1523
Date d'inscription
mardi 18 décembre 2001
Statut
Modérateur
Dernière intervention
21 août 2010
4 -
Pourquoi utiliser Winsock qui est un ActiveX alors que .NET expose ses propre classe de communication ?
TeBeCo
Messages postés
467
Date d'inscription
lundi 24 juin 2002
Statut
Membre
Dernière intervention
9 mars 2011
-
je te conseil de refaire ton code sans l'ocx moisi de vb6
il ne gere pas par exemple la deco : l'event Close est jamais lancé par l'ocx

regarde ce que c que le powa ==> System.Net.Socket

avec ca tu fais un seul NameSpace contenant 2 classe, une client et une serveur
tout ca avec au moins 2 thread par classe pour une gestion des donnée en asychrone qui te permet d'avoir les flux en temp reel

sinon je t'envoi un paquet de 5 Mo, temp qu t'a pas fini de la traiter le petit "coucou" que j'envoi derrière ba tu le voit pas tant que t'a pas traiter l'autre, ou encore si ca plante au milieu le thread est occupé a faire autre chs et ya des vielle erreur ....

enfin bon si tu veux un debut de solution tu va sur =>
www.csharpfr.com source de CraZyHt sur les Socket

enfin biin vala

sinon continu DotNet
cs_Crazyht
Messages postés
1523
Date d'inscription
mardi 18 décembre 2001
Statut
Modérateur
Dernière intervention
21 août 2010
4 -
Merci pour la pub TeBeCo mais en fait il y a meme une version VB.NET de mes sources :)
benefit
Messages postés
5
Date d'inscription
jeudi 30 janvier 2003
Statut
Membre
Dernière intervention
19 mars 2005
-
Merci pour vos commentaires, je prends en comptes vos suggestions.
DxShadow
Messages postés
69
Date d'inscription
samedi 22 décembre 2007
Statut
Membre
Dernière intervention
12 mai 2013
-
"regarde ce que c que le powa ==> System.Net.Socket"

Le Socket de VB.NET? Powa??? Tu causes! Déjà, comment je fais pour le DataArrival ?
Il ne supporte pas les fonctions Handles. (Socket.DataArrival par exemple)

Je préfère utiliser ces nocifs OCX, plutôt que de devoir chercher la petite bête avec VB.NET...
TeBeCo
Messages postés
467
Date d'inscription
lundi 24 juin 2002
Statut
Membre
Dernière intervention
9 mars 2011
-
Je préfère utiliser ces nocifs OCX, plutôt que de devoir chercher la petite bête avec VB.NET...

Edit : plutot que de devoir apprendre a programmer et faire une effort
DxShadow
Messages postés
69
Date d'inscription
samedi 22 décembre 2007
Statut
Membre
Dernière intervention
12 mai 2013
-
Tebeco, tu as l'air en pleine forme :)
Profitons-en, explique-moi alors comment savoir QUAND réceptionner des données avec les sockets de VB.NET, sans timer et sans backgroundworker. Je suis un programmeur propre, je n'aime pas utiliser ces... contrôles hasardeux. Ce n'est pas une question de flemme, ni d'apprentissage, j'apprends le VB.NET depuis Octobre 2007.
cs_Crazyht
Messages postés
1523
Date d'inscription
mardi 18 décembre 2001
Statut
Modérateur
Dernière intervention
21 août 2010
4 -
Dx tu crois vraiement que dans l'OCX de l'epoque, il n'y a pas de timer ?
DxShadow
Messages postés
69
Date d'inscription
samedi 22 décembre 2007
Statut
Membre
Dernière intervention
12 mai 2013
-
Du moins, il n'y en a pas apparant, et on ne doit pas gérer par des timers, mais par des évènements (DataArrival, Connected, ...) et ça c'est cool ^^

Sous VB.NET on peut pas tellement savoir QUAND il y a des envois de données, alors faut toujours télécharger le même fichier ou réceptionner la donnée, ou alors je connais trop mal Socket et ne devrais pas y toucher sans bien le connaître...
TeBeCo
Messages postés
467
Date d'inscription
lundi 24 juin 2002
Statut
Membre
Dernière intervention
9 mars 2011
-
Profitons-en, explique-moi alors comment savoir QUAND réceptionner des données avec les sockets de VB.NET, sans timer et sans backgroundworker. Je suis un programmeur propre, je n'aime pas utiliser ces... contrôles hasardeux

ok la je vais juste extraire la partie amusante :

comment réceptionner des données sans timer .... Je suis un programmeur propre. contrôles hasardeux

Ok donc en fait t'es en train d'essayer de dire que depuis VS2002, les Socket du Framework sont hasardeux mais qu'ils n'ont pas été mis a jouer. Pourquoi pas même si c'est déjà assez ... spécial.
Ensuite en tant que programmeur propre que tu es tu sais qu'on sépare TOUJOURS le Thread UI du/des Thread de "Travail" afin d'éviter que sur une tache longue (genre le téléchargement d'un fichier volumineux ... oups mince par un ... socket) cela de freeze l'UI. A ce niveau la, soit tu thread a la main avec comment la doc le stipule quand tu la lis une jolie petite boucle qui check les donnée entrante, deco etc ..., un backgroundWorker (qui fait la même chose mais qui mache le travail) qui d'ailleurs depuis Lundi peux être remplacé par un "Task" du PFX, et enfin quand tu lis la doc du Socket .net t'as des méthode asynchrone de lecture écriture ...
donc bêtement tu lance une lecture asynchrone et c'est tout... quand il y aura des données a lire le callback le fera et délèguera le traitement a une autre "Task" dont c'est le taff et celui ci (le callback) relancera une lecture asynchrone .... yahoo vive le .net

Pour conclure : Lis la doc de la classe Socket dans MSDN serieusement toutes les reponses sont dedans avec des exemples (et ne parle plus de timer pour les Socket ... je me vois mal expliqué a un client "bonjour je vérifie les donnée toutes X ms, ca ralentit le traitement oui mais bon ... on fait comme on peu"
DxShadow
Messages postés
69
Date d'inscription
samedi 22 décembre 2007
Statut
Membre
Dernière intervention
12 mai 2013
-
<< Ok donc en fait t'es en train d'essayer de dire que depuis VS2002, les Socket du Framework sont hasardeux mais qu'ils n'ont pas été mis a jouer. >>
À jour, plutôt.
On ne peut quand même pas nier que, de toute évidence, le Socket de VB6 est bien plus pratique que celui de VB.NET.

N'importe quel programmeur (pour peu qu'il le soit) dira que le Timer n'est VRAIMENT qu'un dernier recours, et qu'il faut l'éviter.
Quant au backgroundworker, je ne sais pas s'il est idéal aussi, ne pouvant pas modifier le form.
TeBeCo
Messages postés
467
Date d'inscription
lundi 24 juin 2002
Statut
Membre
Dernière intervention
9 mars 2011
-
"On ne peut quand même pas nier que, de toute évidence, le Socket de VB6 est bien plus pratique que celui de VB.NET."
Si totalement et je persiste, ton appli n'est pas portable si tu n'installe pas le runtime vb6 ou l'ocx donc bcp plus contraignant, il ne prend pas en compte les perfs de ton CPU vu que ca reste un OCX donc pas d'évolution par rapport au matériel
donc en gros ca ne sera plus utilisable sur les OS Microsoft a venir, ca n'est pas portable Unix / Mac, et ca n'est pas portable sous un Windows qui utilise mono, belle preuve de praticité.

"Quant au backgroundworker, je ne sais pas s'il est idéal aussi, ne pouvant pas modifier le form." LOAWL
on appel ca de la sécurité ... le cross thread existe depuis (au moins) le framework 2.0 ta réponse me laisse deviner que tu ne sais pas de quoi tu parles ni ce qu'est un délégué (en prog Objet c'est terrible)
Sache qu'on peux acceder au modifié un formulaire depuis un Thread qui n'est pas le thread "Owner" du form, d'ailleurs le backgroundworker est la pour simplifié ce mécanisme, t'as du oublier cette partie dans la doc que tu a surement lue sur le backgroundworker.

Pour conclure je dirais que tu es quelqu'un qui a été forcement de passé a .net contre ta volonté, tu ne montres aucune envies de t'améliorer, d'apprendre, tu énonces des fait contredit dans la doc ou internet que tout le monde peux rapidement trouvé suite à 5 petite minutes d'effort et de motivations sur google.
De plus tu reste bloqué sur ton idée d'utiliser une technologie qui est belle est bien dépassé & plus adapté aux produits actuels.
Mais le plus marrant c'est que tu attache une importance plus que grande a contredire des gens qui ne viennent pas pour critiqué mais pour faire évolué ton code en un produit plus valorisable
DxShadow
Messages postés
69
Date d'inscription
samedi 22 décembre 2007
Statut
Membre
Dernière intervention
12 mai 2013
-
Peu m'importe la portabilité. Je ne m'en suis jamais préoccupé, surtout avec VB.NET.

Inutile aussi de me blâmer/humilier en me faisant la morale, voire me diffamer.
J'ai questionné des amis sur le sujet: Ils étaient à 100% d'accords avec moi.
Les Sockets de VB6 sont vachement plus pratiques que ceux de VB.NET. À quoi bon le compliqué?
Car quand je vois ce code... Je suis rebuté. Malgré plusieurs heures d'efforts, dsl, mais c'est pas super bien foutu. Donc, les préjugés rabaissant... Merci.

Peut-être es-tu un pro du VB.NET et que tu éprouves du plaisir à t'en vanter, mais il est inutile de le montrer tout le temps à la première occasion/personne venue, pour ensuite éventuellement la rabaisser, de manière frustrée. Tu n'es pas ici pour donner ton avis sur les développeurs, mais plutôt pour les comprendre et les aider (du moins je suppose). Bonne soirée, Dx.
TeBeCo
Messages postés
467
Date d'inscription
lundi 24 juin 2002
Statut
Membre
Dernière intervention
9 mars 2011
-
Peut-être es-tu un pro du VB.NET, non

tu éprouves du plaisir à t'en vanter, derniere chose qui me viendrais a l'esprit

mais il est inutile de le montrer tout le temps à la première occasion/personne venue, ca me fait plaisir d'aider désolé si tu le vois autrement

pour ensuite éventuellement la rabaisser, de manière frustrée. J'espere et ne pense pas en etre arrivé a ca, on oppose un point de vue Socket OCX / Socket embed framework je m'avise de défendre mon point de vue, je ne t'y contraint en rien.

Tu n'es pas ici pour donner ton avis sur les développeurs, mais plutôt pour les comprendre et les aider (du moins je suppose). Les comprendres non en aucun cas je pense pas avoir le temps, les aider oui pour ca que la première choses que j'ai fait a été de te cité la version a jour & un lien vers "comment l'utiliser" désolé d'avoir aider