De rien.
Normalement il y a une zone "Donner une note à ce code source" dans le bloc "Ajouter un commentaire".

Ca ne me renseigne pas plus, mais je vais supposer qu'on parle d'un conflit avec la classe partielle définie dans Form1.designer.cs quand on crée un projet sous VS2005 et supérieurs :

Ce bout de code a été fait à l'époque .NET 1.1, c'est-à-dire avant l'apparition des classes partielles.
Il faut donc remplacer complètement les fichiers du "Form1" (.cs et .designer.cs) créé dans un projet .NET 2.0+ par celui-là.
Et il faut aussi supprimer la méthode Main, vu qu'elle existe déjà dans Program.cs

Du genre ?

Tiens justement j'ai lu un truc sur le même sujet il y a peu : http://blogs.msdn.com/b/fiddler/archive/2011/03/09/mapping-socket-or-port-to-owner-process-in-c-sharp-dotnet.aspx

Pour la partie fermeture c'était probablement en utilisant SetTcpEntry (http://msdn.microsoft.com/en-us/library/aa366378.aspx).

Salut,

C'est normal dans cet exemple le TextBox n'est que la cible des actions des boutons, aucun comportement n'est lié aux actions effectuées dessus.

Merci :)

Salut Krimog,

J'ai jeté un oeil à la classe ThreadWorker et j'ai quelques remarques (du coup c'est raté pour l'indulgence, mais il vaut mieux ça que d'avoir des problèmes en prod ;-)).


Thread-safety :

- tu devrais peut être préciser qu'une instance de la classe ThreadWorker en elle même ne doit pas être manipulée par plusieurs threads en même temps (sinon tu as des conditions de race, notamment dans la méthode Start)

- thread-safe ou pas, tu dois synchroniser tous les accès aux champs partagés par plusieurs instances de la classe : l'utilisateur externe ne peut pas le faire sans synchroniser lui même les accès à toutes les instances (ce qui est en général impossible) et de toute façon il n'a même pas conscience de devoir le faire :-)
Dans le cas présent il faut que tu synchronises les accès à _twList car List<T> n'est pas thread-safe.
Dans le cas contraire tu pourras te retrouver avec quelques problèmes en cas d'exécution de Add/Remove lors d'une énumération.

- pour les mêmes raisons, tu devrais peut être changer l'implémentation de la propriété RunningThreadWorkers pour qu'elle retourne une copie de la liste et non pas directement la référence à la liste interne : tu ne pourras pas synchroniser les accès externes, sauf si tu gères la synchro interne via ICollection.SyncRoot et que l'utilisateur dans la classe s'en sert aussi (mais c'est quasiment sûr qu'il oubliera)
Du coup tu as maintenant un problème de performance en cas d'utilisation brutale (polling) de cette propriété, et donc un choix à faire : est-il vraiment utile de l'exposer ? (si oui, il faudra peut être considérer la transformer en méthode, pour mettre plus en avant le fait qu'un appel à un certains coût).



Divers :

- la propriété RunningThreadWorkers devrait être marquée static (là je pense que c'est un simple oubli)

- dans la méthode Start tu lèves 2 exceptions "ArgumentException", alors que la méthode ne prend pas de paramètres. Dans le cas présent je pense qu'il faudrait plutôt utiliser InvalidOperationException (c'est sans doute aussi le cas pour les levées de UnauthorizedAccessException)

- "if (_startNow) _timer_Elapsed(_timer, new EventArgs());" : en général j'évite d'écrire ce genre de chose et préfère déporter le code du gestionnaire d'évènement "_timer_Elapsed" dans une méthode qui sera appelée des 2 endroits : on ne s'attend pas vraiment à ce qu'un gestionnaire d'évènement soit appelé autrement que par la levée de l'évènement.

Salut Dugnouf,

Je n'ai pas regardé ce sujet depuis un bon bout de temps, mais à ma connaissance ce n'est possible qu'en passant par WMI ou certaines API Win32 (OpenProcessToken etc).

Bonjour,

Quand c'est possible stocker la date sous un type datetime et pas varchar/nvarchar (ou char/nchar) sera encore plus simple.

De rien :-)