Stratégie de programmation Visual C#

Bonjour,

Je suis débutant en programmation, je ne suis pas aussi un professionnel, je veux savoir la stratégie (les lois les bases) de programmation en C#

j'explique encore, alors j'ai développé quelque application en utilisant VB.NET, en VB.NET je ne suis pas sensé de connaitre beaucoup des astuces de programmation pour concevoir une application par contre j'ai commencer à utilise le C# et je me bloque plusieurs fois face à des problèmes qui ne se pose pas en VB.NET

Ce que j'ai compris donc est que le langage C# est beaucoup plus stricte que le VB.NET

Voila un petit exemple pour mieux comprendre à quoi je parle :

j'ai une formulaire "ParentForm" et je veux récupérer sa largeur : "ParentForm.ClientRectangle.Width" :

En VB.NET je m'en fou de l'emplacement et/ou du timing d'appel de cette variable et elle sera mise à jour à chaque appel
En C# je déclare une instance de ma formulaire dans une classe publique : "public static ParentForm Acceuille = new ParentForm();" et je me suis obligé de déclarer une variable publique "LargeurParentForm" puis dans l’événement Resize de ma formulaire je met : "LargeurParenForm = this.ClientRectangle.Width"
Quelqu'un peut m'expliquer comment C# réfléchit ? et est-ce-que je dois par exemple bien maîtriser les événements pour dépasser c'est problèmes là ? et/ou d'autre choses ?

Merci d'avance

Cordialement

Salut,

Normalement il n'y a aucunes differences entre C# et vbnet homris la syntaxe et deux trois specificites.

Du coup je dois dire que je ne comprends pas vraiment le probleme.

Tu peux nous dire ou fais-tu ton appel:

Code:

---

ParentForm.ClientRectangle.Width

---

Et quel est le lien entre la classe apellante et ParentForm ?

Merci mermich pour la réponse

Je t'explique mieux par un autre exemple type qui montre la différence entre VB.NET et C#, soit l'exemple suivant "modifier un contrôle d'une Formulaire appelante depuis une Formulaire appelée":

une formulaire "Form1" contient une DataGridView "DGVF1" appelle une deuxième formulaire "Form2"
"Form2" contient un TextBox "TBF2" et un bouton "Afficher s'il Existe"
le bouton "Afficher s'il Existe" teste l’existence de la valeur tapée sur le TextBox "TBF2", si la valeur existe alors la ligne correspondante dans le DataGridView "DGVF1" sera sélectionnée en bleu

Cet exemple est se réalise avec VB.NET d'une manière très simple mais par contre en C# (ce que j'ai compris à travers des recherches) il doit être réaliser à travers des événements un peu compliqué qu'avec VB.NET !

bonjour

Ce que tu avances n'est clair que pour toi....
Ensuite tu reduis la programmation en vb.net et c# à des astuces ....
Si tu veux apprendre valablement le VB.net comme le c# ,il faut refaire les tutos du forum au MINIMUM...et bien connaitre la programmation POO....
Ensuite pour que les gens du forums repondent à ta question ,il faut poster le code vb.net fonctionne et le code c# qui pose probleme en utilisant la balise code(diese)...
Sinon on pourra "discutailler" des centaines de page comme ca sans resultat....

Et mermich sera bien embarasse....

ArtherKing > Ce que tu cites, ce sont des bidouilles de VB6 qui ont été portées dans VB.NET histoire que les devs VB soient pas complètement perdus.

VB6 est abandonné.
Il y a de bonnes raisons pour que ces "astuces" ne fonctionnent pas avec d'autres langages (celle-ci en particulier, je me suis aussi posé la question à mes débuts en C#) qui sont très bien expliquées dans la MSDN.

Bref, sorti de ces "astuces", C# et VB.NET (mais aussi d'autres langages, il y a eu J#, PHP.NET, COBOL.NET, pour ne citer qu'eux) sont tous équivalents, pour la simple et bonne raison que le moteur qui les fait tourner ensuite, c'est le même.

Et il vaut mieux partir de C#, qui est "LE" langage .NET que pousse Microsoft, pour ensuite le comparer avec VB.NET et les autres, plutôt que l'inverse.
=> Quand tu regardes le Paris-Dakar, les temps sont par rapport au premier, pas par rapport au dernier.

Citation:

---

Envoyé par ArtherKing

j'ai une formulaire "ParentForm" et je veux récupérer sa largeur : "ParentForm.ClientRectangle.Width" :

---

Attention, le lien entre deux forms n'est pas de l'héritage à ce niveau là : la page appelée ne connait rien de la page appelante !

Tu peux faire hériter tes forms d'une classe BaseForm avec une propriété de type Form qui récupère la form appelante :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

using System.Windows.Forms;   public class BaseForm : Form { public Form Parent { get; set; }   public BaseForm(Form parent) { this.Parent = parent; } }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public class ParentForm : BaseForm { [...]   public OnClick() // méthode d'exemple :) { [...] ChildForm formAppelee = new ChildForm(this); formAppelee.Show(); } }

---

Et dans ta form appelée, tu pourras utiliser Parent.UnControleDeParentForm.

Il n'y a que moi que ça choque qu'il est déclaré sa parentform en variable statique ?

Une variable statique ? Où ça ?

Une variable statique, ça n'a rien à voir avec ça, puisqu'il s'agit d'une variable sur une classe qu'on n'a pas besoin d'instancier (par exemple pour un singleton).

Ici, chaque Form doit avoir une référence à sa Form appelante.
Je ne vois pas où est le problème philosophique... Tu connais le nom de tes gamins, et tes gamins te connaissent, non ?

Donc si tu veux qu'une Form puisse discuter avec une autre, elle doit la connaître. C'est au contraire la base de la sécurité dans un programme : ça évite d'accéder à tout et n'importe quoi sans savoir d'où ça vient. Et d'avoir la fenêtre lambda qui plante quand on ferme la fenêtre gamma sans avoir la moindre idéede pourquoi.

Ce que fait VB.NET (je décris un principe, pas le fonctionnement réel, qui diffère peut-être) c'est qu'il déclare en variable globale chaque instance de Form.
Perso, ça me choque car :
- les variables globales c'est le mal
- ça encombre inutilement la mémoire et le processeur
- pour le développeur, finalement ça n'apporte franchement rien

Citation:

---

Envoyé par StringBuilder

Ce que fait VB.NET (je décris un principe, pas le fonctionnement réel, qui diffère peut-être) c'est qu'il déclare en variable globale chaque instance de Form.
Perso, ça me choque car :
- les variables globales c'est le mal
- ça encombre inutilement la mémoire et le processeur
- pour le développeur, finalement ça n'apporte franchement rien

---

oui c'est bien pire que ca !
cette variable générée à la compilation semble beaucoup plus aléatoire, quand on a qu'une instance on s'attendrait à la retrouver, et pourtant des fois ca fait un new (donc une nouvelle instance, ce qui peut causer des problèmes !)
et quand on veut utiliser plusieurs instances d'une classe form, ca en met une à jour, mais pas toujours la dernière instanciée semble t il


par contre les variables globales, je ne vois pas en quoi c'est le mal, si tu as besoin d'un truc partout autant qu'il soit accessible de partout
concernant l'encombrement de la mémoire et du processeur, je me demande bien pourquoi l'utilisation du mot encombrement pour un truc dérisoire
et pour le développeur ca apporte facilité et bug


enfin bref si je croise celui chez ms qui a eut l'idée de mettre ca sur vb.net ... :lol:

C'est pas tant la création de la référence et sa taille qui peuvent bouffer des ressources, mais la gestion.

Sinon, les variables globales c'est le mal :

Exemple de script VB :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

dim i = 1   sub test1() dim i = 3 end sub   sub test2() msgbox i test1 msgbox i end sub   call test2()

---

Enjoy !

Ou comment se retrouver avec des variables de type valeur qui se comportement comme si c'était des types référence...

Citation:

---

En C# je déclare une instance de ma formulaire dans une classe publique : "public static ParentForm Acceuille = new ParentForm();"

---

Je parlais de ça il a déclaré sa parentform en tant que static, ce qui est une très mauvaise idée je pense.

Citation:

---

Envoyé par StringBuilder

Ce que fait VB.NET (je décris un principe, pas le fonctionnement réel, qui diffère peut-être) c'est qu'il déclare en variable globale chaque instance de Form.
Perso, ça me choque car :
- les variables globales c'est le mal
- ça encombre inutilement la mémoire et le processeur
- pour le développeur, finalement ça n'apporte franchement rien

---

C'est pas vraiment global ; la possibilité de se référer à une instance par défaut ayant le même nom que la classe (par défaut, ou le chemin complet avec namespace en cas de collision de noms) n'est qu'un raccourci syntaxe vers My.Forms.NomForm qui lui même renvoie à Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OpenForms avec ApplicationBase une version spécialisée de la classe Application (qui possède aussi OpenForms).

Ça n'encombre absolument pas la mémoire, le processeur ou quoi que ce soit d'autre ; car elles ne sont pas crées d’emblée ; un simple AutreForm Is Nothing 'ou My.Forms.AutreForm Is Nothing suffira à confirmer que ce n'est créer que lorsque c'est nécessaire (c'est à dire la première fois qu'on utilisera le Form en question dans le code [sur le même principe que l'initialisation des champs static/Shared d'une classe]). Là où on est d'accord c'est que si on créé à la main Dim f As New AutreForm ce ne sera pas la même instance que celle contenue dans My.Forms (et donc suggèrerait de ne pas les créer à la main mais ça ce n'est plus le même sujet) ; heureusement on peut aussi assigner Nothing à ces instances quand on veut (ce qui les ferme proprement au passage en appelant Close dessus)

Sinon ça n'apporte en effet pas grand chose pour le développeur actuel ; par contre pour le développeur des débuts de VB.Net (ou le pauvre malheureux qui aurait à migrer une application VB6 demain :aie:) ça lui sera utile et je dirais ne devrait être utile qu'à lui ; c'est pour cette raison que l'on peut aussi le désactiver (suffit juste de changer une constante de compilation)

Après on pourrait débattre du pourquoi "ils" ont gardé ça ou pourquoi "ils" ont pas mis désactivé par défaut etc. mais c'est le problème de tout langage avec une Histoire ; alors c'est sûr C# n'a pas ce problème il a été conçu en piochant les idées chez les voisins (C++, Java au moins) et sans avoir de "lignage" à assurer du coup ça simplifie beaucoup de choses. De l'autre côté VB.Net paie les difformités de son ancêtre :lol: ah la famille on la choisit pas :aie:

Citation:

---

Envoyé par StringBuilder

C'est pas tant la création de la référence et sa taille qui peuvent bouffer des ressources, mais la gestion.

Sinon, les variables globales c'est le mal :

Exemple de script VB :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

dim i = 1   sub test1() dim i = 3 end sub   sub test2() msgbox i test1 msgbox i end sub   call test2()

---

Enjoy !

Ou comment se retrouver avec des variables de type valeur qui se comportement comme si c'était des types référence...

---

Là va falloir m'expliquer où est le problème à part que le code ne compile pas en VB.Net parce que le i "global" (donc champ de classe) n'est pas typé explicitement (mais mettons que ce soit un oubli) et qu'il manque les parenthèses d'appel au niveau du MsgBox (ou alors tu crois que VBA == VB.Net et là ça explique beaucoup de choses :lol:) (je zappe le warning sur le i du test1 inutilisé ;)) sinon le code affiche 2 fois "1" ce qui est le comportement normal et attendu ; et ce même code mis en C# fonctionne exactement de la même manière.

Citation:

---

Envoyé par StringBuilder

C'est pas tant la création de la référence et sa taille qui peuvent bouffer des ressources, mais la gestion.

---

noyage de poisson ?

Citation:

---

Envoyé par StringBuilder

Sinon, les variables globales c'est le mal :

Exemple de script VB :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

dim i = 1   sub test1() dim i = 3 end sub   sub test2() msgbox i test1 msgbox i end sub   call test2()

---

Enjoy !

Ou comment se retrouver avec des variables de type valeur qui se comportement comme si c'était des types référence...

---

chez moi ca fait 1 et 1
déjà il faut les bonnes options de compilation (option strict on obligatoire à mon gout)
de 2 il faut des conventions de nommage
de 3 je ne vois pas de rapport entre ce code et une variable globale, enfin je pensais plus à une static property quelque part ...
après je pourrais te parler de la sensibilité à la casse de c# qui laisse écrire 2 variables avec une majuscule de différence, là je trouve ca plus critiquable

Citation:

---

Envoyé par youtpout978

Je parlais de ça il a déclaré sa parentform en tant que static, ce qui est une très mauvaise idée je pense.

---

s'il n'en veut qu'un ca ressemble presque à un singleton ^^

Citation:

---

Envoyé par Sehnsucht

pourquoi "ils" ont pas mis désactivé par défaut etc.

---

ca se désactive ??

Citation:

---

Envoyé par Pol63

ca se désactive ??

---

bah oui

mouais ... je suis allergique aux choses compliquées pour rien ... une case à cocher j'aurais pris ....

je vois pas trop ce qu'il y a de compliqué à rajouter _MYTYPE="Empty" dans les flags de compilation (surtout que c'est accessible dans les propriétés du projet) :aie:
http://i.imgur.com/C0dEgpXt.png?1

pas compliqué à faire certes
mais ce n'est pas parlant, on est plusieurs sur les projets certes personne n'ira voir si quelqu'un à écrit quelque chose ici, mais bon c'est pour le principe
j'ai passé l'age (plutot l'année) de taper des lignes de commandes parce qu'un éditeur de logiciel a été fainéant sur l'interface :D

Citation:

---

Envoyé par Sehnsucht

Là va falloir m'expliquer où est le problème à part que le code ne compile pas en VB.Net parce que le i "global" (donc champ de classe) n'est pas typé explicitement (mais mettons que ce soit un oubli) et qu'il manque les parenthèses d'appel au niveau du MsgBox (ou alors tu crois que VBA == VB.Net et là ça explique beaucoup de choses :lol:) (je zappe le warning sur le i du test1 inutilisé ;)) sinon le code affiche 2 fois "1" ce qui est le comportement normal et attendu ; et ce même code mis en C# fonctionne exactement de la même manière.

---

Il s'agit d'un VBScript, donc pas VB.NET, ni VB6 ni VBA, mais VBS.

Donc pas de static, parenthèses et types, et déclarations optionnelles.

En fait, le code qui marche, et produit un comportement impossible à debugger, c'est celui-là :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

i = 1   sub test1() i = 3 end sub   sub test2() msgbox i test1 msgbox i end sub   call test2()

---

Le fait qu'on puisse, à l'intérieur d'une procédure, modifier une variable déclarée dans un autre scope est une source de bugs impossible à démerder.

En effet, avec un "dim" dans test1, ça pose plus de problème. Mais sans dim, au lieu de planter, ça fait de ma merde.

Étant donné que VBScript a été créé par Microsoft pour être leur version de javascript ; je ne suis pas surpris par ce comportement (qui est le même que dans javascript) ; où une valeur assignée à une variable non-déclarée (via var) appartient au scope global (même si ça se déroule dans une fonction) du coup on a :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

i = 1; //var i = 1; // ici ça ne changerait rien ; en dehors de fonction c'est le scope global   function test1 () { i = 3; // appartient au scope global ; donc référence le i global //var i = 3; // appartient au scope local ; donc masque le i global }   function test2 () { console.log (i); test1 (); console.log (i); }   test2 (); // affichera 1 puis 3 sans var dans test1 // affichera 1 puis 1 avec var dans test1

---

Par contre faudra m'expliquer ce qu'un exemple de VBScript vient faire dans le sujet ; c'est pas parce que ça a VB dans le nom et que les mots clefs utilisés sont les mêmes (sans doute justement parce qu'il y a VB dans le nom) qu'il faut tout mettre ensemble et dire que c'est la même chose :D

VBScript n'est pas un "concurrent de JavaScript" ou autre, mais avant tout de descendant de Basic (au même titre que VB d'ailleurs).
C'est depuis "toujours" le langage utilisé pour faire des macro Office (VBA n'est qu'une sourcouche de VBS), qui est bien plus ancien que Internet Explorer. On trouvait notamment VBA dans Word 2 pour Windows 3.1 alors qu'il n'existait pas de version d'internet explorer sur cette version de Windows (seulement 3.11)

Bref, et en Basic, il n'y avait pas de Dim.
On ne pouvait travailler qu'en global.

Et sinon, cet exemple vient pour illustrer le danger de la programmation à partir de variables globales (ce qui est impossible en .NET, mise à avec avec VB.NET dans quelques cas précis).

Quant au lien entre Basic et VB.NET, il est bien présent, puisque 90% des syntaxes étranges de VB.NET (qui vont à l'encontre des bonnes pratiques de n'importe quel langage moderne) sont là uniquement pour que les dinosaures qui ont débuté l'informatique avec Basic ne soient pas trop perdus.

Et la preuve que c'est "utile", ce topic existe.

PS : Et ne me dites pas qu'un singleton est une variable globale. C'est une "bidouille" pour reproduire, entre autres, un comportement proche des variables globales, mais ça n'a rien à voir !

Pour simuler "vraiment" des variables globales,il faudrait passer en paramètres à toutes les fonctions un "object[]" contenant une référence vers toutes les instances de tous les objets et variables déclarées (en gros, on ne déclare plus de variables, on se contente de travailler avec cet array d'objects).

Là où ça se complique, avec les variables globales, c'est quand on commence à avoir plusieurs niveaux d'imbrication, avec certains niveaux qui vienne écraser les variables déclarées dans un scope parent (pas forcément global), et d'autres travailler avec des valeurs locales.

Bref, vous ne me ferez pas démordre que les variables globales c'est le mal. C'est pas pour rien qu'elles n'existent plus dans aucun langage moderne.

J'ai assez galéré en maintenance de sites ASP pour savoir de quoi je parle ! Et encore, je n'ai pas abordé les variables globales partagés entre instances ou non (variables Session et Application) dans un contexte ASP.

Faudra m'expliquer comment VBA (créé en 1993) peut être une surcouche de VBS (créé en 1996) :lol:
VBA est une implémentation de VB (créé en 1991) spécifique à l'environnement office ; et partage le même runtime que VB (msvbvmxx.dll avec xx la version)
VBS est dérivé de VB ; autrement dit il partage une syntaxe similaire mais n'a pas le même runtime (il utilise vbscript.dll au lieu du runtime VB)

Dim existait déjà en BASIC (et même dans sa toute première version le Dartmouth BASIC de 1964) et ne servait alors qu'à Dimensionner les tableaux.

Depuis VB (peut-être même avant [GW-BASIC & cie par exemple]; à vérifier) les globales ne sont plus l'unique scope ; en VB il existait 3 scopes le global, le scope module et le scope local.
Depuis VB.Net ; le scope global n'existe plus ; par contre il y a moyen (assurant la rétrocompatibilité) de simuler cette globalité ; pour exemple et rejoindre avec le sujet initial du topic ; les "Form accessibles par défaut" proviennent d'une "Factory de Singleton" (My.Forms) avec la simplicité d'écriture de pouvoir omettre ce conteneur ; et comme tu l'as dit un singleton n'est pas une globale :)

Quant à l'utilité de ce topic ; à la base, c'était car quelqu'un ne comprenait pas une différence entre C# et VB.Net ; là ça dérive plus dans une croisade "anti-VB" ce qui est ton droit mais ce n'est pas trop l'endroit :)

étrange cette haine envers vb.net :D
moi je le trouve bien ^^

Citation:

---

Envoyé par StringBuilder

90% des syntaxes étranges de VB.NET

---

le chiffre est gros et est peut-être pas loin de la vérité, mais ce n'est qu'un effet d'annonce ; des syntaxes étranges en vb.net il y en a peu, et on peut s'en passer

après soit les variables globales existent en vb.net et elles existent aussi en c# (oui je ne sais toujours pas ce que tu entends pas variable globale du coup)
soit elle n'existe dans aucun des 2
donc pourquoi continuer d'en parler et dériver sur des langages des années 90 pour essayer d'avoir raison (en vain selon Sehnsucht)

le raccourci de vb.net évoqué au début du topic est certes une aberration mais ce n'est pas une variable globale selon ta description