Discussion :

[tssi555]

Bonjour,

En VB.NET, on déclare une variable globale dans un module, et on la manipule partout dans le projet.
Quel est l'équivalent de cela en C#?
J'ai fais recours à une solution "provisoire?" en déclarant mes variables en public statique dans la class Program, puis j'y accède partout dans le projet en écrivant Program.MaVariable, est-ce la bonne manière ?

En VB.NET, pour accéder à un contrôle (objet) Text1.Text de Form1, c'était en général le NomDeLaForm.NomDuControl. Je ne parviens pas à faire pareil en C#, les contrôles sont crée en private par le designer.
Quel est l'équivalent de cela en C#?
J'ai procédé autrement à mon mode, mais je ne sais pas si je suis sur la bonne piste. J'applique un Get sur le contrôle en le rendant public mais je ne suis pas sûr que ce serait le plus propre.

D'avance merci.

[BenoitM]

Bonjour,

En VB.NET, on déclare une variable globale dans un module, et on la manipule partout dans le projet.
Quel est l'équivalent de cela en C#?
J'ai fais recours à une solution "provisoire?" en déclarant mes variables en public statique dans la class Program, puis j'y accède partout dans le projet en écrivant Program.MaVariable, est-ce la bonne manière ?

Euh oui C'est la bonne manière, mais on essaye d'avoir le moins possible recourt aux variables globales.
De plus on aura plus tendance a créer plusieurs petites classes statiques. (ou utiliser l'appConfig)
Exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
public static class DbConnnection
{
public static string ConnectionString{get;set}
}

En VB.NET, pour accéder à un contrôle (objet) Text1.Text de Form1, c'était en général le NomDeLaForm.NomDuControl. Je ne parviens pas à faire pareil en C#, les contrôles sont crée en private par le designer.
Quel est l'équivalent de cela en C#?
J'ai procédé autrement à mon mode, mais je ne sais pas si je suis sur la bonne piste. J'applique un Get sur le contrôle en le rendant public mais je ne suis pas sûr que ce serait le plus propre.
D'avance merci.

C'est la méthode VB6, pas VB.Net au mieux de mauvaise pratique hérité de VB6
Soit tu passes des arguments à ta form en définisant un nouveau constructeur
Soit tu crées des propriétés comme tu l'as fait.
Euh le plus joli est de crée une propriété sur le .Text par exemple que sur le controle
une autre est de crée une propriété qui renvois un objet
exemple ma FormEtudiant avec des texbox nom,prénom,datedenaisse à une methode GetEtudiant() qui fait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
public Etudiant GetEtudiant()
{
Etudiant myEtudiant = new Etudiant()
myEtudiant.Nom = tbNom.Text;
myEtudiant.Prenom = tbPrenom.Text;
return myEtudiant;
}

Attention que les propriétés de la form n'existe plus quand tu fermes la forme

Une autre méthode, et nettement plus élégante est d'utilisé les delegates pour la communication entre tes forms communication between form

[GuruuMeditation]

Je ne connais pas trop vb mais je pense que effectivement l'équivalent pour variable globale est la classe statique.

Pour le second point, si je me rappelle bien, il y a une propriété "modifier" (ou un truc du genre) dans le designer qui permet de mettre les contrôles en public. Cependant je ne conseille pas et suggère de passer plutôt par des propriétés/ méthodes.

[tssi555]

Merci Benoit, merci Olivier,

C'est vrai qu'à la base, je viens du monde VB6, puis passé au VB.NET. période dans laquelle j'ai hérité pas mal de pratiques reliées au VB6, dont j'essaye de me défaire en programmant actuellement en C#.

Pour le mot clé "static", j'ai lu certaines définitions sur le net, mais je ne pense pas avoir assimilé tout le concept, ou plutôt son utilité.
Pourriez-vous m’éclairer là dessus?

D'autre part, quand je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public string NameServer
{
get { return txtNameServer.Text; }
}

-si j'ajoute le mot clé "static" après "public", txtNameServer devient invisible dans la liste, une fois retiré j'ai accès au contrôle.

[BenoitM]

Static c'est pour définir quelque chose de globale.

Tu peux définir une classe static alors tout ses méthodes/propriétés seront unique

Au niveau d'une propriété/méthode/champs celui-ci sera commun alors à toute les classes

Exemple un compteur qui serait en static

Une méthode/propriété static ne peut appeller que des methodes/propriété/champs static

une méthode static s'appelle via la class et non une instance de la class
Etudiant.Compteur et non myEtudiant.Compteur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public string NameServer
{
get { return txtNameServer.Text; }
}

tu ne peux pas car tu fais appelle a txtNameServeur qui est une variable non static.
txtNameServeur dépend de ta forme actuel.
Tu peux imaginer lancer 2 fois la meme form et mettre dans txtNameServeur deux valeurs différentes

[Bluedeep]

Static c'est pour définir quelque chose de globale.

Dans le cas d'une classe, en général oui, mais pas obligatoirement. Dans le cas une méthode ou d'un membre, pas forcément non plus : une méthode ou un membre "private static" est courant.

Equivalent VB.Net : Shared

Tu peux définir une classe static alors tout ses méthodes/propriétés seront unique

Doivent être static. Mais pas uniques : les règles de surcharges pour les méthodes statiques sont les mêmes.

Au niveau d'une propriété/méthode/champs celui-ci sera commun alors à toute les classes

Ce n'est pas exact. Une classe static privée interne à une autre classe, donc avec une visibilité limitée à cette dernière, est parfaitement licite.

[BenoitM]

Dans le cas d'une classe, en général oui, mais pas obligatoirement. Dans le cas une méthode ou d'un membre, pas forcément non plus : une méthode ou un membre "private static" est courant.

Dans le cas d'une méthode celle-ci est "globale" à la classe
Dans le cas d'un field, celui-ci est "globale" pour la classe (partagé par toutes ses instances)

Doivent être static. Mais pas uniques : les règles de surcharges pour les méthodes statiques sont les mêmes.

Oui mal exprimé et je pensais fields surtout au fields qui est (unique) partagé par toutes les instances.
C'est bien de VB Shared c'est plus compréhensible que static :p

Ce n'est pas exact. Une classe static privée interne à une autre classe, donc avec une visibilité limitée à cette dernière, est parfaitement licite.

Ah oui quand même
C'est une question que tu poses aux interviews? :p

Déja définir des classes internes, ca m'arrive rarement mais alors une classe interne static