Bonjour à tous,
 
J'ai un petit soucis avec une ListView.
Je récupère un certain nombre de résultat dans mon code qui est situé dans la form1
J'aimerais via une liste view situé dans ma Form4 pouvoir récupérer ses resultats.
Comment dois je déclarer mes variables pour qu'elles soient accessibles via toutes les Forms.
J'ai cette erreur:  
Erreur 1 Le nom 'critik_Name n'existe pas dans le contexte actuel C:\projects\Form4.cs  
 
D'avance merci
Cdlt
Junt

Mettre ta listview publique ?
Créer les méthodes qui vont bien dans ta form4 pour ajouter des résultats ?
Ya plein de manières de faire, hein...

Le plus propre serait même de globaliser la source plutot que de partager le listview

Merci pour vos conseils , je vais donc globaliser ma source.
A+
Junt

Tiens, ça m'intéresse...
 
Comment "globaliser" ?
 
Jusqu'à présent, le seul moyen que je connaisse pour utiliser un truc global, c'est d'avoir un Dictionnary<string, object> nommé "Context", que je me trimballe partout, mais c'est un peu très chiant comme truc, et si y'a moyen de faire des variables globales, ça m'intéresse carrément... On fait comment ?

 
Le meilleur moyen c'est de bien détacher le contexte donnée du contexte d'affichage. Les exemples d'implémentation de MVC ne manque pas
 
Idéalement, si c'est possible et que le contexte s'y prete, c'est de passer par un singleton

Rien compris
 
Concrètement, ça donne quoi ? Dans un langage non-objet ou semi-objet comme le C ou le C++, il suffit de déclarer une variable en dehors d'une class/fonction pour qu'elle soit visible de partout. Mais en C# ?

 
En C#, tu oublie le concept de variable déja
 
Ensuite, un petit tour par ici sera instructif http://www.dofactory.com/Patterns/Patterns.aspx  
 
puis pour le MVC (Model/View/Control)
 
Model : Concretement, tes données
View  : La reperésentation de tes données (tes fenetres/User control/Pages web, etc)
Control : Comment tu geres tes données par rapport à tes vues
 
http://www.c-sharpcorner.com/Uploa [...] c5d1141e3f
 
Lorsque tu geres tes applis en respectant ces concept, tes données sont complémetement détachées de l'affichage, cela te permet de développer par exemple une implémentation Web et une implémentation client lourd sur la même couche de donnée (que l'on appelle courament couche Métier).
 

Euh...
 
Ouais, nan mais ça je suis d'accord.
 
Mais mettons un exemple tout bête : J'ai un fichier INI dans lequel je peux décider de quelle couleur afficher les background de mes Forms.
 
A part me faire chier à passer cette variable systématiquement au constructeur de chaque Form créée (ou via une méthode, propriété, ou ce que tu veux), je préfèrerais être capable par exemple de taper un truc genre :
 
this.BackgroundColor = Global.BackgroundColor;
 
Et que "MyParams" soit accessible de n'importe où (du moins, de n'importe quelle Form) sans que je doive me faire chier à le trimballer à chaque fois.
 
C'est à cause de ça que j'utilise maintenant un Dictionary pour passer mes "variables globales", parcequ'au moins ça m'évite de devoir me repalucher 20000 lignes de code pour ajouer une variable en paramètre dans un constructeur quand je décide de rajouter un truc.
 
En fait, si tu fais de l'ASP.NET, ce que je veux, c'est avoir un objet qui ait un scope gloabl comme les collections Session, Application ou Request.
On peut les appeler de n'importe où et c'est bien pratique.

 
Tes problèmes sont différent :
 
1ere chose : L'héritage, tu crée une classe implémentant ta gestion de backround, elle même héritant de System.Windows.Forms.Form puis tes tu dérives tes classes de fenetre de ta nouvelle classe.
 
2eme : concernant la création de classe ayant le même comportement que la classe session par exemple. La classe session, justement, est une propriété publique( ou protected) de la classe Page dont dérive ta page Aspx, cette propriété, est du type  HttpSessionState, dont l'implémentation pourrait se faire via une classe singleton Static
 
Interet du singleton Static: le constructeur n'est appelé qu'a la premiere utilisation de l'objet, c'est à ce moment que tu crée ton objet (ex: lecture du fichier ini, etc...). Ensuite, partout dans ton application, lorsque tu fais référence à ton objet, il est utilisé tel que tu l'a crée à l'initialisation.
 
Exemple Minimaliste d'implémentation :
 

 
Avec ceci, lorsque tu va appeler la propriété "ProprieteBidon" de la classe, le constructeur static sera automatiquement appellé à la premiere execution, ensuite, partout ou tu appelera
 
TestSingleton.ProprieteBidon tu utilisera l'instance initialisée en static sans repasser par le constructeur
 
Attention, ici ce n'est pas un véritable singleton, mais cela te donne une idée du concept. L'idéal etant de réaliser une véritable implémentation de singleton (telle que décrite dans mon premier lien) avec ce concept de constructeur static.

Tu veux dire que si j'ai ça :
 

public class Test1
{
    public Test1()
    {
        MessageBox.Show(TestSingleton.ProprieteBidon);
    }
}
 
public class Test2
{
    public Test2()
    {
        MessageBox.Show(TestSingleton.ProprieteBidon);
    }
}
 
public class Form1 : Form // Ma form
{
    void Test()
    {
        Test1 t1 = new Test1();
        Test2 t2 = new Test2();
    }
}

 
Ca ne va appeler qu'une fois le constructeur de TestSingleton ???
 
Si c'est ça, c'est exactement ce qu'il me faut !!!

public class Test1
{
    public Test1()
    {
        MessageBox.Show(TestSingleton.ProprieteBidon);
    }
}
 
public class Test2
{
    public Test2()
    {
        MessageBox.Show(TestSingleton.ProprieteBidon);
    }
}
 
public class Form1 : Form // Ma form
{
    void Test()
    {
        Test1 t1 = new Test1();
        Test2 t2 = new Test2();
    }
}

 
 
T'as plus qu'a compiler et tester

Et en plus ça marche !!!
 
Merci infiniment, là franchement, je sais plus quoi dire, je t'aime !
 

class Context
    {
        private static Dictionary<string, object> m_list;
 
        public static Dictionary<string, object> Parameters
        {
            get
            {
                return m_list;
            }
        }
 
        static Context()
        {
            MessageBox.Show("context constructor" );
            m_list = new Dictionary<string, object>();
            m_list.Add("p1", "test" );
            m_list.Add("p2", 42);
        }
    }

 
=> D'où que j'appelle mes paramètres : 1/ le constructeur ne tourne effectivement qu'une fois 2/ ils sont disponibles
 

 
c'est la "magie" (en fait ya rien de magique, c'est de la logique ) des concepts objets, les design patterns et le C# qu'il faut remercier