visual studio - ¿Cuál es el estado del juego con "Herencia visual"?

visual-studio winforms

Question

Tenemos una aplicación que tiene que ser flexible en la forma en que muestra su forma principal para el usuario, dependiendo del usuario, el formulario 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 confirmarlo? ¿Me falta algo aquí?

Saludos.

Answer 1

A menudo me tropiezo con tales problemas en Visual Studio. En muchos casos, el diseñador de formularios MSVS no procesa 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 2

Creo que he encontrado una forma de evitar este problema.

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

Tampoco elimine el constructor vacío predeterminado de Visual Studio en el formulario principal. Si quieres tener Dependency Injection, crea otro constructor.

Me gusta esto:

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

Luego puede hacer esto desde su Formulario heredado:

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

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

salud, Daniel

Answer 3

Estoy estudiando para la MCAD (que, por cierto, pronto será obsoleta), y parte del elemento de WinForms fue Integridad visual.

Personalmente no he tenido grandes problemas con esto, sin embargo, hay consideraciones que hay que tener en cuenta .

Para mí, el problema principal siempre tiene la inicialización . Debe recordar que el diseñador no puede / no crea instancias de formularios de la misma forma que lo hace en tiempo de ejecución (de manera similar, no puede hacer esto con el desarrollador web, por lo que es necesario tener cuidado). con renderizado de control personalizado).

Además, una vez que se cambia un 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 evidencia que sugiera que ha sido "rechazado". AFAIK, sigue siendo una buena práctica para ejercer el código de reutilización cuando sea posible. Herencia visual proporciona eso.

¿Puedo sugerir que crees una nueva pregunta con los problemas reales que tienes, con un código de muestra? Luego 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 recuerdo es genéricos en las clases de formularios

public class MyForm<MyObject> : Form

esto no funcionará

Answer 5

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

AFAIK, todavía hay problemas con la herencia visual y los objetos que se basan en colecciones para los elementos de diseño, por lo general, controles de cuadrícula, etc. Creo que MS aún ha 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 VI usando controles de cuadrícula de terceros, pero hay que tener cuidado, en particular, se DEBEN eliminar los elementos de las colecciones.

Answer 6

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

• Sin tipos de control abstractos
• Sin argumentos de constructor en ninguna forma
• La inicialización se movió a Form_Load en comparación con el Ctor
• No hay controles en el mismo proyecto que el usercontrol / formulario que se colocan dentro
• Cierre todos los documentos -> Limpiar -> Reconstruir
• Reiniciar VS

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