Quel est l’état d’avancement de « l’héritage visuel » ?

Question

Nous avons une application qui doit être flexible dans la façon dont elle affiche son formulaire principal à l'utilisateur - selon l'utilisateur, le formulaire doit être légèrement différent, peut-être un bouton supplémentaire ici ou là, ou une autre nuance.Afin d'arrêter d'écrire du code pour supprimer ou ajouter explicitement des contrôles, etc., je me suis tourné vers l'héritage visuel pour résoudre le problème - dans ce que je pensais être un style OO soigné, propre et logique - il s'avère que la moitié du temps, les formulaires hérités ont du mal le rendu lui-même dans VS sans raison valable, etc. - et j'ai le sentiment que les développeurs et, dans une certaine mesure, Microsoft ont évité la pratique de l'héritage visuel - pouvez-vous le confirmer, est-ce que j'ai raté quelque chose ici ?

Salutations.

Answer 1

Je pensais qu'ils avaient plus ou moins réglé les problèmes de conception de bureau en 2005.Avez-vous essayé les coupables habituels ?

• Aucun type de contrôle abstrait
• Aucun argument de constructeur sous quelque forme que ce soit
• Initialisation déplacée vers Form_Load par opposition au Ctor
• Aucun contrôle dans le même projet que le contrôle utilisateur/formulaire dans lequel ils sont placés
• Fermez tous les documents -> Nettoyer -> Reconstruire
• Redémarrer VS

Il me semblait que tant que vous faisiez tout ce qui précède, cela fonctionnait.....surtout.

Answer 2

J'étudie vers le MCAD (certes bientôt obsolète), et une partie de l'élément WinForms était l'héritage visuel.

Personnellement, je n'ai eu aucun problème majeur avec cela, mais là sont des considérations à prendre en compte.

Pour moi, le problème principal a toujours été l'initialisation..Vous devez vous rappeler que le concepteur ne peut pas/n'instancie pas les formulaires de la même manière qu'il le fait au moment de l'exécution (de même, il ne peut pas le faire avec le développement Web, c'est pourquoi il faut faire attention au rendu des contrôles personnalisés).

Aussi, une fois qu'un formulaire est modifié, une reconstruction complète du projet est nécessaire afin de propager les modifications du formulaire aux formulaires enfants qui en héritent.

Personnellement, je n'ai vu aucune preuve suggérant qu'il ait été « boudé ». AFAIK, c'est toujours une bonne pratique d'exercer la réutilisation du code lorsque cela est possible.L'héritage visuel fournit cela.

Puis-je suggérer de créer une nouvelle question avec le réel problèmes que vous rencontrez, avec un exemple de code ?Nous pouvons ensuite l'examiner pour voir si nous pouvons le faire fonctionner et expliquer pourquoi :)

Answer 3

J'ai vu quelques problèmes dans VS2005 avec ça.Ils étaient principalement dus à des problèmes de construction des formes-objets chez le concepteur.Il y avait des problèmes avec le code qui tentait d'accéder à la base de données à partir des constructeurs de formulaires, etc.

Vous pouvez déboguer des problèmes comme celui-ci en démarrant une deuxième instance de Visual Studio et en chargeant la première instance dans le débogueur.Si vous définissez des points d'arrêt dans votre code, vous pouvez alors déboguer ce qui se passe dans les concepteurs en premier lieu.

Un autre problème dont je me souviens était celui des génériques dans les classes de formulaire.

public class MyForm<MyObject> : Form

ça ne marchera pas

Answer 4

Je tombe souvent sur de tels problèmes dans Visual Studio.Dans de nombreux cas, le concepteur de formulaires MSVS ne parvient pas à restituer correctement le formulaire.À l'époque où je travaillais avec WinForms, je devais faire toutes sortes d'astuces étranges pour activer certains scénarios complexes.Cependant, je pense que l'utilisation de l'héritage visuel est très bénéfique et ne doit pas être abandonnée, quels que soient les bogues du concepteur MSVS.

Answer 5

Je pense avoir trouvé un moyen d'éviter ce problème.

N'accrochez pas l'événement Form_Load dans votre formulaire parent, cela briserait le concepteur.

Ne supprimez pas non plus le constructeur vide par défaut de Visual Studio dans le formulaire parent.Si vous souhaitez avoir une injection de dépendances, créez un autre constructeur.

Comme ça:

public ProductDetail()
{
    InitializeComponent();
}

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

Vous pouvez alors toujours le faire à partir de votre formulaire hérité :

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

Cela a fonctionné pour moi jusqu'à présent, et j'ai également eu des problèmes de conception étranges.

bravo, Daniel

Answer 6

Lis ça: http://cs.rthand.com/blogs/blog_with_righthand/archive/2005/11/10/186.aspx

AFAIK, il existe toujours des problèmes avec l'héritage visuel et les objets qui reposent sur des collections pour les éléments de conception, généralement des contrôles de grille, etc.Je crois que MS a toujours supprimé la possibilité de changer f.ex.un GridView dans un formulaire/contrôle utilisateur hérité, etc.Mais d'autres contrôles comme TextBox, Form, UserControl, Panel etc.devrait fonctionner comme prévu.

Jusqu'à présent, je n'ai eu aucun problème avec VI utilisant moi-même des contrôles de grille tiers, mais vous devez être prudent, en particulier, la suppression d'éléments des collections DOIT être évitée.