UTILISATION DE WINSOCK POUR VB.NET
cs_max12
Messages postés
1491
Date d'inscription
dimanche 19 novembre 2000
Statut
Modérateur
Dernière intervention
7 juillet 2014
-
16 mars 2005 à 21:58
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
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
https://codes-sources.commentcamarche.net/source/30151-utilisation-de-winsock-pour-vb-net
19 avril 2010 à 01:03
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
18 avril 2010 à 22:57
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.
18 avril 2010 à 22:39
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
17 avril 2010 à 14:48
À 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.
17 avril 2010 à 03:46
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"
11 avril 2010 à 11:30
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...
11 avril 2010 à 09:37
10 avril 2010 à 14:48
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.
9 avril 2010 à 17:00
Edit : plutot que de devoir apprendre a programmer et faire une effort
4 avril 2010 à 13:20
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...
19 mars 2005 à 09:04
19 mars 2005 à 00:31
18 mars 2005 à 23:35
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
17 mars 2005 à 14:31
16 mars 2005 à 21:58