Qual è la situazione attuale con "Visual Inheritance"

Question

Abbiamo un'applicazione che deve essere flessibile nel modo in cui mostra il suo modulo principale all'utente: a seconda dell'utente, il modulo dovrebbe essere leggermente diverso, forse un pulsante aggiuntivo qua o là o qualche altra sfumatura.Per smettere di scrivere codice per rimuovere o aggiungere esplicitamente controlli ecc., mi sono rivolto all'ereditarietà visiva per risolvere il problema - in quello che pensavo fosse uno stile OO pulito, pulito e logico - risulta che la metà delle volte i moduli ereditati hanno difficoltà renderizzando se stessi in VS senza una buona ragione ecc. - e ho la sensazione che gli sviluppatori e in una certa misura Microsoft abbiano evitato la pratica dell'ereditarietà visiva - puoi confermarlo, mi sto perdendo qualcosa qui?

Saluti.

Answer 1

Pensavo che nel 2005 avessero più o meno risolto i problemi del desktop designer.Hai provato con i soliti colpevoli?

• Nessun tipo di controllo astratto
• Nessun argomento del costruttore in alcuna forma
• L'inizializzazione è stata spostata su Form_Load invece che su Ctor
• Nessun controllo nello stesso progetto del controllo utente/modulo in cui sono inseriti
• Chiudi tutti i documenti -> Pulisci -> Ricostruisci
• Riavvia VS

Mi sembrava di pensare che finché facevi tutto quanto sopra funzionava .....soprattutto.

Answer 2

Sto studiando per il MCAD (certamente presto obsoleto) e parte dell'elemento WinForms era Visual Inheritence.

Personalmente, però, non ho avuto grossi problemi lì sono considerazioni di cui tenere conto.

Per me, il problema principale è sempre l'inizializzazione..È necessario ricordare che il progettista non può/non crea un'istanza dei moduli nello stesso modo in cui lo fa in fase di esecuzione (allo stesso modo, non può farlo con lo sviluppo web, motivo per cui è necessaria attenzione con il rendering del controllo personalizzato).

Anche, una volta modificato un modulo, è necessaria una ricostruzione completa del progetto per propagare le modifiche al modulo ai moduli figli che ereditano da esso.

Personalmente non ho visto alcuna prova che suggerisca che sia stato "evitato". Per quanto ne so, è ancora buona pratica esercitare il riutilizzo del codice ove possibile.L'ereditarietà visiva lo fornisce.

Posso suggerire di creare una nuova domanda con effettivo problemi che riscontri con il codice di esempio?Possiamo quindi guardarlo per vedere se riusciamo a farlo funzionare e spiegare perché :)

Answer 3

Ho riscontrato alcuni problemi in VS2005 con questo.Erano per lo più dovuti a problemi con la costruzione delle forme-oggetto nel designer.Si sono verificati problemi con il codice che tentava di accedere al database dai costruttori di moduli, ecc.

Puoi eseguire il debug di problemi come questo avviando una seconda istanza di Visual Studio e caricando la prima istanza nel debugger.Se imposti dei punti di interruzione nel tuo codice puoi quindi eseguire il debug di ciò che accade nei progettisti in prima istanza.

Un altro problema che ricordo erano i generici nelle classi dei moduli

public class MyForm<MyObject> : Form

questo non funzionerà

Answer 4

Spesso mi imbatto in tali problemi in Visual Studio.In molti casi il progettista dei moduli MSVS non riesce a eseguire il rendering corretto del modulo.Ai tempi in cui lavoravo con WinForms dovevo fare tutti i tipi di strani trucchi per abilitare alcuni scenari complessi.Tuttavia penso che l'utilizzo dell'ereditarietà visiva sia molto vantaggioso e non dovrebbe essere buttato via indipendentemente dai bug del designer MSVS.

Answer 5

Penso di aver trovato un modo per evitare questo problema.

Non collegare l'evento Form_Load nel modulo principale, questo interromperà il designer.

Inoltre, non rimuovere il costruttore vuoto predefinito da Visual Studio nel modulo padre.Se vuoi avere l'inserimento delle dipendenze, crea un altro costruttore.

Come questo:

public ProductDetail()
{
    InitializeComponent();
}

public ProductDetail(ISupplierController supplierController) : base()
{
    InitializeComponent();
    this.supplierController = supplierController;
}

Puoi quindi ancora farlo dal tuo modulo ereditato:

public NewProduct(ISupplierController supplierController)
    : base(supplierController)
{
    InitializeComponent();
}

Finora ha funzionato per me e ho avuto anche alcuni strani problemi con il designer.

saluti, Daniele

Answer 6

Leggi questo: http://cs.rthand.com/blogs/blog_with_righthand/archive/2005/11/10/186.aspx

Per quanto ne so, ci sono ancora problemi con l'ereditarietà visiva e gli oggetti che si basano su raccolte per gli elementi di progettazione, in genere controlli a griglia, ecc.Credo che MS abbia ancora rimosso la possibilità di cambiare f.ex.un GridView in un modulo/controllo utente ereditato ecc.Ma altri controlli come TextBox, Form, UserControl, Panel ecc.dovrebbe funzionare come previsto.

Finora non ho avuto problemi con VI utilizzando personalmente i controlli della griglia di terze parti, ma devi stare attento, in particolare, la rimozione di elementi dalle raccolte DEVE essere evitata.