Le meilleur moyen d'accéder à un contrôle sur une autre forme dans les Windows Forms?

Au lieu de faire de la commande publique, vous pouvez créer une propriété qui contrôle sa visibilité:

public bool ControlIsVisible
{
     get { return control.Visible; }
     set { control.Visible = value; }
}

Cela crée un bon accesseur pour que le contrôle qui ne sont pas exposer le contrôle de l'ensemble des propriétés.

La première ne fonctionne pas bien. Les contrôles sur un formulaire sont privée, visible uniquement pour la forme par la conception.

Pour rendre tout cela public est également pas la meilleure façon.

Si je voudrais exposer quelque chose du monde extérieur (qui peut aussi signifier une autre forme), je fais un bien public pour elle.

public Boolean nameOfControlVisible
{
    get { return this.nameOfControl.Visible; }
    set { this.nameOfControl.Visible = value; }
}

Vous pouvez utiliser cette propriété publique pour masquer ou afficher la commande ou de demander le contrôle de la visibilité actuelle de la propriété:

otherForm.nameOfControlVisible = true;

Vous pouvez également exposer tous les contrôles, mais je pense que c'est trop beaucoup, vous devez vous rendre visible uniquement les propriétés que vous voulez vraiment utiliser de l'extérieur de la forme actuelle.

public ControlType nameOfControlP
{
    get { return this.nameOfControl; }
    set { this.nameOfControl = value; }
}

Supposons que vous avez deux formes, et que vous souhaitez masquer la propriété d'une forme par une autre:

form1 ob = new form1();
ob.Show(this);
this.Enabled= false;

et quand vous voulez obtenir le focus de form1 par form2 sur le bouton:

Form1 ob = new Form1();
ob.Visible = true;
this.Close();

1. Utiliser un gestionnaire d'événements pour informer les autres de la forme de la manipuler.
2. Créer une propriété publique sur le formulaire d'enfant et d'y accéder à partir du formulaire parent (avec une pièce en fonte).
3. Créer un autre constructeur, sur le formulaire d'enfant pour le réglage de la forme de paramètres d'initialisation
4. Créer des événements personnalisés et/ou de l'utilisation (statique) des classes.

La meilleure pratique #4 si vous utilisez les formulaires non modale.

Avec la propriété (en surbrillance) je peux obtenir l'instance de la MainForm classe. Mais c'est une bonne pratique? Que recommandez-vous?

Pour cela, j'utilise la propriété MainFormInstance qui s'exécute sur la méthode OnLoad.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using LightInfocon.Data.LightBaseProvider;
using System.Configuration;

namespace SINJRectifier
{

    public partial class MainForm : Form
    {
        public MainForm()
        {
            InitializeComponent();
        }

        protected override void OnLoad(EventArgs e)
        {
            UserInterface userInterfaceObj = new UserInterface();
            this.chklbBasesList.Items.AddRange(userInterfaceObj.ExtentsList(this.chklbBasesList));
            MainFormInstance.MainFormInstanceSet = this; //Here I get the instance
        }

        private void btnBegin_Click(object sender, EventArgs e)
        {
            Maestro.ConductSymphony();
            ErrorHandling.SetExcecutionIsAllow();
        }
    }

    static class MainFormInstance  //Here I get the instance
    {
        private static MainForm mainFormInstance;

        public static MainForm MainFormInstanceSet { set { mainFormInstance = value; } }

        public static MainForm MainFormInstanceGet { get { return mainFormInstance; } }
    }
}

@Lars, bon appel sur la passant autour de la Forme des références, vu ainsi moi-même. De méchant. Jamais vu d'entre eux sont passés à la couche BLL si! Qui n'a même pas de sens! Qui pourrait avoir d'importantes répercussions sur les performances? Si quelque part dans la BLL la référence a été conservé, le formulaire de rester dans la mémoire de droit?

Vous avez toute ma sympathie! 😉

---

@Ed, RE votre commentaire à propos de rendre les modes UserControls. Dylan l'a déjà souligné que la racine instancie de nombreux enfant formes, donnant l'impression d'une application MDI (où je suis en supposant que les utilisateurs peuvent vouloir fermer les diverses Formes). Si je suis bon dans cette hypothèse, je pense qu'ils seraient les mieux gardés comme des formes. Tout à fait ouvert à la correction bien 🙂

Vous ne devriez jamais accéder à un point de vue du contenu à partir d'un autre si vous êtes en train de créer plus de commandes complexes/modules/composants. Sinon, vous devez le faire par le biais de la norme de conception Modèle-Vue-Contrôleur de l'architecture: vous devez Vous connecter à l'état activé des contrôles vous vous souciez de pour certains au niveau du modèle de prédicat qui fournit la bonne information.

Par exemple, si je voulais activer un bouton Enregistrer uniquement lorsque toutes les informations ont été entrées, j'aurais un prédicat méthode qui indique si le modèle d'objets représentant la forme, sont dans un état qui peut être sauvé. Ensuite, dans le contexte où je suis pour choisir d'activer le bouton, je voudrais utiliser le résultat de cette méthode.

C'est beaucoup plus propre séparation de la logique métier de la présentation de la logique, permettant à la fois de leur évolution de façon plus autonome, vous permettant de créer un front-end avec plusieurs back-end, ou plusieurs front-end avec un seul back-end avec facilité.

Il sera aussi beaucoup, beaucoup plus facile à écrire unitaires et des tests d'acceptation, parce que vous pouvez suivre un "Faire Confiance, Mais Vérifier" modèle en procédant de la sorte:

1. Vous pouvez écrire un ensemble de tests de configurer votre modèle d'objets de différentes façons, et vérifier que le "sauvé" le prédicat renvoie un résultat approprié.

2. Vous pouvez écrire un ensemble distinct de vérifier si votre bouton de sauvegarde est connecté d'une façon appropriée à la "sauvé" le prédicat (tout ce qui est de votre cadre, en Cocoa sur Mac OS X ce serait souvent par une liaison).

Tant que les deux séries de tests sont de passage, vous pouvez être sûr que votre interface utilisateur va travailler de la façon dont vous le souhaitez.

Étape 1:

string regno, exm, brd, cleg, strm, mrks, inyear;

protected void GridView1_RowEditing(object sender, GridViewEditEventArgs e)
{
    string url;
    regno = GridView1.Rows[e.NewEditIndex].Cells[1].Text;
    exm = GridView1.Rows[e.NewEditIndex].Cells[2].Text;
    brd = GridView1.Rows[e.NewEditIndex].Cells[3].Text;
    cleg = GridView1.Rows[e.NewEditIndex].Cells[4].Text;
    strm = GridView1.Rows[e.NewEditIndex].Cells[5].Text;
    mrks = GridView1.Rows[e.NewEditIndex].Cells[6].Text;
    inyear = GridView1.Rows[e.NewEditIndex].Cells[7].Text;

    url = "academicinfo.aspx?regno=" + regno + ", " + exm + ", " + brd + ", " +
          cleg + ", " + strm + ", " + mrks + ", " + inyear;
    Response.Redirect(url);
}

Étape 2:

protected void Page_Load(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
        string prm_string = Convert.ToString(Request.QueryString["regno"]);

        if (prm_string != null)
        {
            string[] words = prm_string.Split(',');
            txt_regno.Text = words[0];
            txt_board.Text = words[2];
            txt_college.Text = words[3];
        }
    }
}

Changement modificateur public interne. .Net utilise délibérément privé modificateur au lieu de le public, en raison de prévenir tout accès illégal à vos méthodes/propriétés/contrôle de votre projet. En fait, le public modificateur peut accessibles de partout, de sorte qu'Ils sont vraiment dangereux. Tout le corps de votre projet peut accéder à vos méthodes/propriétés. Mais, En interne, pas de modificateur de corps (d'autres de votre projet en cours) peuvent accéder à vos méthodes/propriétés.

Supposons que vous créez un projet, qui a un secret les domaines. Donc, Si ces champs étant accessible de votre projet, il peut être dangereux, et à l'encontre de vos idées initiales. Comme une bonne recommandation, je peux dire toujours utiliser internes modificateur au lieu de public modificateur.

Mais une étrange!

Je dois dire aussi dans VB.Net alors que nos méthodes/propriétés sont encore privés, il peut être accessible à partir d'autres formes/classe en appelant le formulaire comme une variable sans aucun problème ailleurs.

Je ne sais pas pourquoi dans ce langage de programmation comportement est différent de C#. Comme nous le savons tous les deux sont en utilisant la même Plate-forme et ils prétendent qu'ils sont presque la même extrémité Arrière de la Plateforme, mais comme vous le voyez, ils continuent de se comporter différemment.

Mais j'ai résolu le problème avec les deux approches. Soit; à l'aide de l'Interface (Qui n'est pas à recommander, comme vous le savez, les Interfaces ont généralement besoin modificateur public, et à l'aide d'un modificateur public n'est pas recommandé (Comme je vous l'ai dit ci-dessus)),

Ou

Déclarer la totalité de votre Forme en quelque part de classe statique et statique de la variable, et il est encore interne modificateur. Puis, quand vous supposez que de l'utiliser pour montrer aux utilisateurs, donc passer de nouvelles Form() la construction de cette classe statique/variable. Maintenant, Il peut être Accessible à tous où que vous le souhaitez. Mais vous avez encore besoin de quelque chose de plus.
Vous déclarez votre élément interne modificateur de trop dans le Fichier de Concepteur de Formulaire. Alors que votre Formulaire est ouvert, il peut être accessible de partout. Il peut fonctionner très bien pour vous.

Considérer Cet Exemple.

Supposons que vous souhaitez accéder à une Forme de zone de texte.

De sorte que la première tâche est la déclaration d'une variable statique dans une classe statique (La raison de la statique est la facilité d'accès, sans l'aide de nouvelles clétage à l'avenir).

Seconde aller à la classe de concepteur de Formulaire qui suppose d'être accessible par d'autres Formes. Le changement de son modificateur de zone de texte de la déclaration de privé interne. Ne vous inquiétez pas; .Net ne jamais changer de nouveau pour le privé modificateur après votre évolution.

Troisième, quand vous voulez l'appeler, qui forme à s'ouvrir pour passer à la nouvelle Forme de la Construction de cette variable statique-->>static de la classe.

Quatrième; de toutes les autres Formes (où que ce soit dans votre projet, vous pouvez accéder à cette forme de contrôle/alors que Depuis est ouverte.

Regardez le code ci-dessous (Nous avons trois objets.
1 - une classe statique (dans notre exemple nous le nom A)

2 - Toute Forme d'autre qui veut ouvrir la Forme finale (a zone de texte, dans notre exemple FormB).

3 - La Forme réelle qui nous devons être ouverts, et nous supposons qu'à l'accès à son intérieur TextBox1 (dans notre exemple FormC).

Regarder les codes ci-dessous:

internal static class A
{
    internal static FormC FrmC;
}

FormB ...
{
    '(...)
    A.FrmC = new FormC();
    '(...)
}

FormC (Designer File) . . . 
{
     internal System.Windows.Forms.TextBox TextBox1;
}

Vous pouvez accéder à cette Variable statique (ici FormC) et de son contrôle interne (ici Textbox1) partout et chaque fois que vous le souhaitez, tout en FormC est ouvert.

---

Tout Commentaire, idée, laissez-moi savoir. Je heureux de vous entendre ou de tout le corps d'autre à propos de ce sujet plus. Honnêtement, j'ai eu quelques problèmes à l'égard de ce problème dans le passé. Le meilleur moyen est la deuxième solution qui, je l'espère, il peut travailler pour vous. Laissez-moi savoir toute nouvelle idée/suggestion.