Delegate et méthode anonyme

ah il te met la variable privée ?
c'est étrange il ne me le fait jamais ...
j'ai due rééditer un prog que j'ai fait en VB.NET là, et non rien à faire, je trouve l'écriture des propriétés toujours aussi merdique...

t'aurais pas installé une extension particulière ? non parce que bon il y a pas mal de projets dans la boite écrits en VB... donc quand je dois y retoucher.
non parce que je l'ai installé chez moi et même constat... ou alors c'est un code snippet et dans ce cas ce n'est plus trop l'intellisense...

j'ai activé toutes les options de l'éditeur VB à part l'espace virtuel, donc bon...

non c'est meme précisé ici et là sur internet dans les améliorations de vs 2010

d'ailleurs tu peux tester, tu marques public property a as string
et dans un sub tu fait me._a = "test"

et le compilateur laisse passer
c'est du code implicite

m'enfin vaut mieux arreter là cette discussion stérile, les 2 langages sont identiques hormis la syntaxe et un ou deux détails, et l'ide est légèrement différent selon le langage

tiens différence notable d'intellisense vraiment merdique à souhait...

au moins avec C# quand tu implémente un interface, tu peux lui demander de te faire l'implémentation implicite ou explicite...
en vb.net rien du tout, les options sur les interfaces... il n'y en a pas.

j'en souffre pas mal là, surtout avec des interfaces complexes comme IDictionary(Of TKey,TValue) que tu n'arrive pas a implémenter car il se plante lamentablement sur les enumérateurs, il t'en faut 2, mais quand tu veux déclarer celui qui enumère les KeyValuePair<TKey,TValue> il gueule, comme quoi il en fait pas parti...
et si tu le met pas il gueule comme quoi t'a pas totalement implémenté l'interface.
t'avouera que là... dans le genre connerie monumentale... ca se pose là.

n'oublions pas le plus simple

1/declaration un nouveau type

Code:

---

Private Delegate Sub ChangeLog(ByVal Valeur As String)

---

2/instance

Code:

---

1 2 3 4 5

Dim monDelegate as New Delegate ChangeLog(adressof,AddLog)   Public Sub AddLog(ByVal maChaine As String) txLog.Text = AppendText(Valeur) End Sub

---

3/ si on veut utiliser Invoke sur le controle txtLog c'est qu'il s'excute sur un thread different probablement sinon c'est pas la peine invoke

4/supposons le alors c'est un schema classique pour tous les controles Winforms car ils sont les seuls qui sont cross-thread et peuvent se marshaller des appels vers eux meme a travers les frontieres de thread en utilisant les methodes Invoke ou beginInvoke & endInvoke (par le biais des delegues).

pour cela il faut une classe wrapper- appartenant- au nouveau thread qui recoit un parametre pointeur sur le formulaire actuel (("qui invokera plus tard le delegue")

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

Private monThread As Thread   'demarre le nouveau thread monThread = New Thread(New ThreadStart(AddressOf ProcThread)) monThread.Start()   Private Sub ProcThread() 'cree une instance qui appartient au nouveau thread Dim ObjThreadClass As New maClasseThread(Me) ObjThreadClass.Methode() End Sub 'ThreadFunction End Class   'classe auxiliaire Public Class maClasseThread Private maForme As Form2 'refer instance du formulaire principal   Public Sub New(ByVal xForme As Form2) maForme = xForme End Sub 'New Private maChaine As String   Public Sub Methode()   maChaine = "Step number " + i.ToString() + " executed" Thread.Sleep(400) 'l'instance du fomulaire peut faire un appel inter-thread à elle meme avec la methode Invoke (marshalle methode+parametre) car elle appele son delegate qui est dans un thread different du thread actuel (monThread) le delegate s'executera asynchroniquement et affichera la valeur. if maForme.txtLog.InvokeRequired then maForme.Invoke(maForme.monDelegue, New Object() {maChaine}) else txtLog.Append(maChaine) End Sub End Class

---

ici une instance du formulaire suffit pour retrouver le controle txtLog car Invoke balaye tous les controles enfants.
mais ouf avec la synchronisation car si le controle txtLog est cree au run-time apres avoir demarre le nouveau thread c'est le crash car le delegate va appeler sur la propriete d'un controle qui n'existe pas.

ou bien pire si au runtime on s'avise de supprimer le controle alors que le thread va appeler sur lui plus tard.

c'est pour cela que la synchronisation est le point faible des threads et qu'il faut utiliser les methodes de synchronisation (mutex,resetevent et autre...).
bon code....

Citation:

---

Envoyé par cinemania

Pol63 et bien les constructions syntaxiques désolés mais tu admettra que jusqu'à récemment... elles n'étaient pas supportées.

je ne sais pas si tu trouve cohérent qu'il ait fallut finalement attendre dotnet4 pour que vb intègre une fonctionnalité C# 2.0 comme les méthodes anonymes jusqu'ici impossible ou de pouvoir faire des lambda séquentielles...
alors je me suis peut être avancé trop vite, mais vous avouerez qu'il y a de quoi car la dernière fois que j'ai testé je me suis fait jeté, maintenant c'est vrai j'ai pas vraiment eu l'occasion de rester et surtout ré approfondir depuis VS2010. Alors méa culpa, mais microsoft est pas mal responsable de cela.

quand à l'intellisense... bien disons que sur 2010 il y a des améliorations, mais également des régressions...
installé toutes les versions de 2010 msdn dispo, sur différentes machines, et sur toute j'ai le même résultat, avec et sans extensions...
sous 2008 quand tu tape Property .... () automatiquement il clos la propriété avec le End property qui va bien en te mettant au passage le getter et le setter qui vont bien s'il n'y a pas de readonly ou writeonly...
depuis 2010 oh miracle... il ne le fait plus... il ne le fera que si tu commence à taper get et valide. J'appelle cela une régression.

ce langage est déjà trop verbeux parfois, alors si en plus l'intellisense ne fait même plus le béaba pourtant bien utile pour compenser cette verbosité...

---

Salut,

Je remonte le sujet car je suis pas d'accord avec toi sur un point. Les propriétés sont auto-implémentés maintenant donc plus besoin d’écrire les accesseurs dans beaucoup de cas. Il sont généré pour toi automatiquement...

Je remonte quand même sur le sujet VB différent de C# (au niveau de ce qu'on peut faire).

Même s'il est vrai que les 2 fourches ont tendance à être de plus en plus similaire au point de vue fonctionnel (et c'est la volonté de Microsoft, pas un hasard) il en reste pas que historiquement (et peut être encore 1 ou 2 trucs qui traine aujourd'hui) il y avait des différences entre les possibilités des 2 languages.

Donc pour ceux qui utilise la version 4 du framework, il y a effectivement peu, voir pas de différence sur les 2 languages (au niveau possibilité). Mais pour ceux qui sont restés au versions précédantes, ce n'est pas la même chose!