UserControl come interfaccia, ma visibile in Progettazione

Question

Quindi abbiamo un progetto # WinForms C con un modulo che contiene un bazillion UserControl s. Ogni UserControl espone naturalmente tutti i metodi, proprietà, ecc. UserControl oltre ai propri membri specifici.

Ho pensato che un modo per ridurre la complessità di gestione di questi UserControl s è di accedervi tramite un'interfaccia. Così, invece di drag-and-drop per mettere il UserControl sulla forma, qualcosa di simile nel costruttore:

public class MyGiantForm 
{ 
    ICustomerName cName; 

    public MyForm() 
    { 
     InitializeComponent(); 

     var uc = new SomeCustomerNameUserControl(); 
     this.Controls.Add(uc); 
     cName = uc; 
    } 
} 

SomeCustomerNameUserControl implementa ICustomerName, naturalmente, e ICustomerName contiene le proprietà specifiche che mi interessa (ad esempio, FirstName e LastName). In questo modo posso riferimento alla UserControl attraverso l'elemento cName e, invece di essere travolti da tutti i membri UserControl, ottengo solo quelli in ICustomerName.

Tutto bene, ma il problema è che se lo faccio in questo modo, non riesco a vedere SomeCustomerNameUserControl nella finestra di progettazione. Qualcuno sa che posso farlo ma vedere ancora lo UserControl sulla superficie di progettazione del modulo?

MODIFICA: Un modo per eseguire questa operazione, che non è eccessivamente complicato, consiste nel posizionare i controlli su un modulo di base. Per impostazione predefinita (in C#) i membri del controllo sono privati. Quindi creo una proprietà per ogni controllo esponendolo attraverso l'interfaccia.

Tuttavia, sarei interessato in qualche altro modo per fare questo, anche se è più complesso. Sembra che ci sia un modo per farlo con IDesignerHost, ma non riesco a trovare alcun esempio applicabile.

Answer 1

Dopo aver aggiunto l'UserControl utilizzando il progettista, è possibile impostare GenerateMember su false nella finestra Proprietà per sopprimere la generazione di un membro.

È quindi possibile utilizzare qualche altra tecnica nel costruttore per assegnare il vostro riferimento cName, ad es .:

foreach(Control control in this.Controls) 
{ 
    cName = control as ICustomerName; 
    if (cName != null) break; 
} 

cName sarebbe allora l'unico riferimento alla UserControl.

Answer 2

Se SomeCustomerNameUserControl è definito in questo modo:

class SomeCustomerNameUserControl : UserControl, ICustomerName 
{ 
} 

È ancora possibile eliminare questo controllo nella finestra di progettazione (che crea someCustomerNameUserControl1) e fare questo ogni volta che è necessario:

ICustomerName cName = someCustomerNameUserControl1; 

Forse' Mi manca qualcosa, ma penso che sia così semplice.

Answer 3

si potrebbe anche fare come diceva Bob, ma assegnare tutte le variabili membro nel costruttore, allora si hanno in un unico luogo.

Answer 4

C'è un modo per ottenere ciò che si vuole - nascondere i membri che non si vuole vedere - ma rendono applica automaticamente, senza la necessità di una cooperazione degli altri in termini di loro utilizzando un'interfaccia personalizzata. Puoi farlo reintroducendo tutti i membri che non vuoi vedere e taggandoli con gli attributi.

Questo è ciò che fa Windows Form quando, ad esempio, una proprietà di classe base non significa nulla per un determinato discendente. Ad esempio, Control ha una proprietà Text, ma una proprietà Text non ha senso su, ad esempio, un TabControl. Quindi TabControl sovrascrive la proprietà Text e aggiunge attributi al suo override dicendo "A proposito, non mostrare la mia proprietà Text nella Griglia Proprietà o in Intellisense." La proprietà esiste ancora, ma dal momento che non la vedi mai, non ti ostacola.

Se si aggiunge un [EditorBrowsable (EditorBrowsableState.Never)] attributo a un membro (proprietà o un metodo), quindi Intellisense non sarà più dimostrare che membro nelle sue liste completamento del codice. Se sto capendo correttamente la tua domanda, questa è la grande cosa che stai cercando di ottenere: rendere difficile per il codice dell'applicazione utilizzare il membro per sbaglio.

Per le proprietà, probabilmente anche da aggiungere [sfogliabile (false)] per nascondere la proprietà dalla griglia delle proprietà, e [DesignerSerializationVisibility (DesignerSerializationVisibility.Hidden)] per evitare che il progettista di scrivere il valore della proprietà al file .designer.cs.

Ciò renderà molto difficile l'utilizzo accidentale del metodo/proprietà. Non sono ancora una garanzia, però. Se hai bisogno di una garanzia, inserisci anche un attributo [Obsoleto] e costruisci con "Considera gli avvertimenti come errori" - quindi ti prendi cura di te.

Se il membro di base è virtuale, è probabile che si desideri sovrascriverlo e fare in modo che l'override faccia semplicemente call base. Non lanciare un'eccezione, poiché il membro sottoposto a override verrà probabilmente chiamato dalla classe base durante il normale corso degli eventi. D'altra parte, se il membro base non è virtuale, allora si vuole usare "nuovo" invece di "sovrascrivere", e si può decidere se l'implementazione deve chiamare base, o semplicemente lanciare un'eccezione - nessuno dovrebbe usare il tuo membro reintrodotto comunque, quindi non dovrebbe importare.

public class Widget : UserControl 
{ 
    // The Text property is virtual in the base Control class. 
    // Override and call base. 
    [EditorBrowsable(EditorBrowsableState.Never)] 
    [Browsable(false)] 
    [DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)] 
    [Obsolete("The Text property does not apply to the Widget class.")] 
    public override string Text 
    { 
     get { return base.Text; } 
     set { base.Text = value; } 
    } 

    // The CanFocus property is non-virtual in the base Control class. 
    // Reintroduce with new, and throw if anyone dares to call it. 
    [EditorBrowsable(EditorBrowsableState.Never)] 
    [Browsable(false)] 
    [DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)] 
    [Obsolete("The CanFocus property does not apply to the Widget class.")] 
    public new bool CanFocus 
    { 
     get { throw new NotSupportedException(); } 
    } 

    // The Hide method is non-virtual in the base Control class. 
    // Note that Browsable and DesignerSerializationVisibility are 
    // not needed for methods, only properties. 
    [EditorBrowsable(EditorBrowsableState.Never)] 
    [Obsolete("The Hide method does not apply to the Widget class.")] 
    public new void Hide() 
    { 
     throw new NotSupportedException(); 
    } 
} 

Sì, questo è un bel po 'di lavoro, ma basta farlo una volta ... per ogni membro, per classe ... umm, sì. Ma se quei membri della classe base non si applicano davvero alla tua classe, e averli lì causerà confusione, allora potrebbe valere la pena di andare allo sforzo.

Answer 5

Sembra quasi che si desideri implementare un modello di mediazione. Invece di dover gestire direttamente ciascuno dei miliardi di UserControl, interagiresti con loro attraverso il mediatore. Ogni mediatore definirebbe l'interfaccia sottile che si desidera vedere da ciascun controllo. Ciò ridurrebbe la complessità complessiva rendendo il tuo progetto più esplicito e conciso. Ad esempio, non avresti bisogno delle 20 proprietà e 50 metodi disponibili su uno dei tuoi controlli. Invece dovresti trattare con il mediatore per quel controllo che definisce le 2 proprietà e 5 metodi che ti interessano veramente. Tutto sarebbe ancora presente nel designer, ma altre parti della tua app non interagirebbero con quei controlli: interagirebbero con i mediatori.

Uno dei grandi vantaggi di questo approccio è che semplifica notevolmente la manutenzione. Se si decide che MyCrappyUserControl deve essere riscritto perché l'implementazione è errata, è sufficiente aggiornare la classe mediatore per quel controllo. Tutte le altre classi che interagiscono con il controllo lo fanno attraverso il mediatore e rimarrebbero invariate.

Alla fine si tratta di disciplina: tu e il tuo team dovete essere abbastanza disciplinati da usare i mediatori/interfacce/qualsiasi cosa invece di colpire direttamente i controlli. Installa una revisione del codice spalla da un programmatore capo se la tua squadra si trova nella fascia bassa della scala della disciplina.

Answer 6

È possibile scrivere un metodo di estensione che consente di restituire eventuali controlli nel modulo che implementa un'interfaccia.

public static class FormExtensions 
{ 
    public static IDictionary<string, T> GetControlsOf<T>(this Form form) 
      where T: class 
    { 
     var result = new Dictionary<string, T>(); 
     foreach (var control in form.Controls) 
     { 
      if ((control as T) != null) 
       result.Add((control as T).Tag, control as T); 
     } 
     return result; 
    } 
} 

Poi, nel modulo si potrebbe chiamare dovunque si desidera da:

this.GetControlsOf<ICustomerName>()["NameOfControlHere"]; 

Nel caso in cui restituisce più di un controllo utente che si avrebbe bisogno di gestire che in qualche modo, magari con l'aggiunta proprietà tag all'interfaccia per tenere traccia di ogni univocamente controllo utente o qualcosa, in questo modo

public partial class UserControl1 : UserControl, ICustomerName 
{ 
    public string Tag { get { return this.Name; } } 
} 

È quindi possibile trascinare e rilasciare i controlli utente nel form dal progettista. Tag restituirà sempre il nome del tuo controllo, che ti permetterà di accedere direttamente al controllo attraverso l'interfaccia di IDictionary. Gli sviluppatori potrebbero inserire qualsiasi identificatore univoco che desiderano nel nome del controllo e portarlo all'interfaccia.

Inoltre, è opportuno notare che questo approccio consentirà ANCHE di utilizzarlo su TUTTI i moduli nella soluzione.

L'unica altra cosa che dovresti fare è impostare il tuo GenerateMember su false.

Answer 7

'Voglio che ICustomerName sia l'solo l'opzione per accedere alla variabile UserControl. L'idea è che uno sviluppatore non debba "solo ricordare" di lanciarlo.

Il problema che si verifica è che esistono due usi completamente divergenti per il modulo e i controlli che esso ospita. Non c'è alcun trucco incorporato in Visual Studio o winforms che risolva questo per te. Potrebbe essere possibile, ma esiste un modo molto più pulito e orientato agli oggetti per separare i due metodi di interazione con i controlli.

Se si desidera nascondere il fatto che questi oggetti ereditano da UserControl e si desidera trattarli come IDoSomeThingYouShouldDealWith, è necessario separare la logica che si occupa dei problemi di presentazione (progettazione + logica dell'interfaccia utente) dalla logica aziendale.

La classe del modulo, dovrebbe trattare correttamente i controlli come UserControls, docking, ancoraggio ecc. Ecc., Niente di speciale qui. Dovresti mettere tutta la logica che deve occuparsi di ICustomerName.FirstName = etc in una classe completamente separata. Questa classe non si cura o non conosce i font e il layout, ma sa solo che c'è un'altra istanza che può presentare un nome cliente; o un DateTime come un controllo di data di nascita che sceglie correttamente, ecc.

Questo è un esempio veramente zoppo, ma devo andare adesso. Si dovrebbe essere in grado di ottenere il idea covered here in more detail:

public interface ICustomerName 
    { 
     void ShowName(string theName); 
    } 

    public partial class Form1 : Form, ICustomerName 
    { 
     public Form1() 
     { 
      InitializeComponent(); 
     } 

     #region ICustomerName Members 

     public void ShowName(string theName) 
     { 
      //Gets all controls that show customer names and sets the Text propert 
      //totheName 
     } 

     #endregion 
    } 

    //developers program logic into this class 
    public class Form1Controller 
    { 
     public Form1Controller(ICustomerName theForm) //only sees ICustomerName methods 
     { 
      //Look, i can't even see the Form object from here 
      theForm.ShowName("Amazing Name"); 
     } 
    } 

Answer 8

Si supponga che MyUserControl viene definito in questo modo:

class MyUserControl : UserControl, IMyInterface 
{ 
    // ... 
} 

Poi nel modulo, si dovrebbe avere qualcosa di simile:

public class MyForm : Form 
{ 
    IMyInterface cName; 

    public MyForm() 
    { 
     InitializeComponent(); 

     cName = new MyUserControl(); 
     Controls.Add((UserControl)cName); 
    } 
} 

In questo modo, cName è l'unico modo per accedere a questa istanza del nostro controllo degli utenti.