Cuál es el estado del juego con "Herencia visual"

Question

Tenemos una aplicación que tiene que ser flexible en la forma en que muestra su forma principal para el usuario; según el usuario, la forma debe ser ligeramente diferente, tal vez un botón adicional aquí o allí, o algún otro matiz. Para dejar de escribir código para eliminar o agregar controles explícitamente, etc., recurrí a la herencia visual para resolver el problema, en lo que pensé que era un estilo limpio, limpio y lógico de OO, resulta que la mitad de las veces las formas heredadas tienen dificultades Si me presento en VS sin una buena razón, etc., y tengo la sensación de que los desarrolladores y, en cierta medida, Microsoft han rehuido la práctica de la herencia visual, ¿pueden confirmar esto, me falta algo aquí?

Atentamente.

Answer 1

Pensé que habían ordenado más o menos los problemas del diseñador de escritorio en 2005. ¿Has probado los culpables habituales?

• No hay tipos de control abstractos
• No hay argumentos de constructor en cualquier forma
• inicialización se trasladaron a Form_load en contraposición a la Ctor
• No hay controles en el mismo proyecto que el control de usuario/forma que se ponen dentro
• Cierre todos los documentos -> Clean -> Reconstruir
• Reiniciar VS

Parecía pensar que mientras hicieras todo lo anterior, funcionó ... principalmente.

Answer 2

A menudo me tropiezo con tales problemas en Visual Studio. En muchos casos, el diseñador de formularios MSVS no puede procesar el formulario correctamente. En los días que trabajé con WinForms tuve que hacer todo tipo de trucos extraños para habilitar algunos escenarios complejos. Sin embargo, creo que el uso de la herencia visual es muy beneficioso y no debe desecharse a pesar de los errores de diseño de MSVS.

Answer 3

Estoy estudiando para la MCAD (que se reconoce que pronto será obsoleta), y parte del elemento de WinForms era la herencia visual.

Yo personalmente no he tenido ningún problema importante con él, sin embargo, hay son consideraciones para tener en cuenta.

Para mí, el principal problema siempre ha inicialización .. Es necesario recordar que el diseñador no puede/no crear instancias de las formas de la misma manera que lo hace en tiempo de ejecución (de manera similar, no puede hacer esto con web dev, por eso es necesario tener cuidado con el renderizado de control personalizado).

Además, una vez que se cambia el formulario, se requiere una reconstrucción completa del proyecto para propagar los cambios al formulario a los formularios secundarios que heredan de él.

Personalmente no he visto ninguna evidencia que sugiera que ha sido "rechazada". AFAIK, sigue siendo una buena práctica para utilizar la reutilización de códigos cuando sea posible. Herencia visual proporciona eso.

Puedo sugerir la creación de una nueva pregunta con los problemas reales que está teniendo, con código de muestra? Entonces podemos verlo para ver si podemos ponerlo en funcionamiento y explicar por qué :)

Answer 4

He visto algunos problemas en VS2005 con esto. En su mayoría, se debieron a problemas con la construcción de los objetos de formas en el diseñador. Hubo problemas con el código que intentó acceder a la base de datos desde los constructores de formularios, etc.

Puede depurar problemas como este iniciando una segunda instancia de Visual Studio y cargando la primera instancia en el depurador. Si establece puntos de interrupción en su código, entonces puede depurar lo que sucede en los diseñadores en la primera instancia.

Otro problema que puedo recordar era genéricos en clases de forma

public class MyForm<MyObject> : Form 

esto no funcionará

Answer 5

creo que he encontrado una manera de cómo evitar este problema.

No conecte el evento Form_Load en su formulario principal, esto romperá el diseñador.

Además, no quite el constructor vacío predeterminado de Visual Studio en el formulario principal. Si quieres tener Dependency Injection, crea otro constructor.

De esta manera:

public ProductDetail() 
{ 
    InitializeComponent(); 
} 

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

A continuación, puede todavía hacer esto desde su forma hereditaria:

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

Esto funcionó para mí hasta ahora, y tuve algunos problemas de diseño extraños también.

aplausos, Daniel

Answer 6

Lea esto: http://cs.rthand.com/blogs/blog_with_righthand/archive/2005/11/10/186.aspx

yo sepa, todavía hay problemas con Visual Herencia y objetos que se basan en las colecciones de los elementos de diseño, por lo general los controles de cuadrícula etc. Creo MS todavía han eliminado la posibilidad de cambiar f.ex. un GridView en un formulario heredado/usercontrol, etc. Pero otros controles como TextBox, Form, UserControl, Panel, etc. deberían funcionar como se esperaba.

Hasta ahora no he tenido ningún problema con el uso de controles de cuadrícula de terceros, pero hay que tener cuidado, en particular, se deben evitar los elementos de las colecciones.