Windows Forms ( WinForms ) es una biblioteca de clases gráficas (GUI) gratuita y de código abierto incluida como parte de Microsoft .NET , .NET Framework o Mono [2] , que proporciona una plataforma para escribir aplicaciones cliente para computadoras de escritorio, portátiles y tabletas. [3] Si bien se la considera un reemplazo de la biblioteca Microsoft Foundation Class Library anterior y más compleja basada en C++ , no ofrece un paradigma comparable [4] y solo actúa como una plataforma para el nivel de interfaz de usuario en una solución de múltiples niveles . [5]
En el evento Microsoft Connect del 4 de diciembre de 2018, Microsoft anunció el lanzamiento de Windows Forms como un proyecto de código abierto en GitHub . Se publica bajo la licencia MIT . Con este lanzamiento, Windows Forms se ha vuelto disponible para proyectos que apuntan al marco .NET Core . Sin embargo, el marco todavía está disponible solo en la plataforma Windows, y la implementación incompleta de Windows Forms de Mono sigue siendo la única implementación multiplataforma. [6] [7]
Una aplicación de Windows Forms es una aplicación basada en eventos compatible con .NET Framework de Microsoft . A diferencia de un programa por lotes , pasa la mayor parte del tiempo simplemente esperando que el usuario haga algo, como completar un cuadro de texto o hacer clic en un botón . El código de la aplicación se puede escribir en un lenguaje de programación .NET como C# o Visual Basic .
Windows Forms proporciona acceso a los controles comunes de la interfaz de usuario nativa de Windows al envolver la API de Windows existente en código administrado . [8] Con la ayuda de Windows Forms, .NET Framework proporciona una abstracción más completa por encima de la API de Win32 que Visual Basic o MFC. [9]
Windows Forms es similar a la biblioteca Microsoft Foundation Class (MFC) para el desarrollo de aplicaciones cliente. Proporciona un contenedor que consiste en un conjunto de clases C++ para el desarrollo de aplicaciones de Windows. Sin embargo, no proporciona un marco de aplicación predeterminado como MFC. Cada control en una aplicación de Windows Forms es una instancia concreta de una clase.
Todos los elementos visuales de la biblioteca de clases de Windows Forms se derivan de la clase Control. Esta proporciona la funcionalidad mínima de un elemento de interfaz de usuario, como ubicación, tamaño, color, fuente, texto, así como eventos comunes como hacer clic y arrastrar/soltar. La clase Control también tiene soporte de acoplamiento para permitir que un control reorganice su posición debajo de su elemento principal. La compatibilidad con Microsoft Active Accessibility en la clase Control también ayuda a los usuarios con discapacidades a utilizar mejor Windows Forms. [10]
En Visual Studio, los formularios se crean mediante técnicas de arrastrar y soltar . Se utiliza una herramienta para colocar controles (por ejemplo, cuadros de texto, botones, etc.) en el formulario (ventana). Los controles tienen atributos y controladores de eventos asociados a ellos. Los valores predeterminados se proporcionan cuando se crea el control, pero el programador puede cambiarlos. Muchos valores de atributos se pueden modificar durante el tiempo de ejecución en función de las acciones del usuario o los cambios en el entorno, lo que proporciona una aplicación dinámica. Por ejemplo, se puede insertar código en el controlador de eventos de cambio de tamaño del formulario para cambiar la posición de un control de modo que permanezca centrado en el formulario, se expanda para rellenar el formulario, etc. Al insertar código en el controlador de eventos para una pulsación de tecla en un cuadro de texto, el programa puede traducir automáticamente el texto que se está introduciendo entre mayúsculas y minúsculas o incluso evitar que se inserten determinados caracteres.
Además de proporcionar acceso a controles nativos de Windows como botones, cuadros de texto, casillas de verificación y listas de visualización, Windows Forms agregó sus propios controles para alojamiento ActiveX , organización de diseños, validación y vinculación de datos enriquecidos. Esos controles se representan mediante GDI +. [10]
Al igual que Abstract Window Toolkit (AWT), la API equivalente de Java , Windows Forms fue una forma temprana y sencilla de proporcionar componentes de interfaz gráfica de usuario a .NET Framework . Windows Forms se basa en la API de Windows existente y algunos controles simplemente envuelven los componentes subyacentes de Windows. [11] Algunos de los métodos permiten el acceso directo a las devoluciones de llamadas Win32 , que no están disponibles en plataformas que no sean Windows. [11]
En .NET Framework 2.0, Windows Forms obtuvo controles de diseño más completos, controles de barra de herramientas al estilo de Office 2003, componentes multihilo, soporte de enlace de datos y tiempo de diseño más completo, así como ClickOnce para implementación basada en web. [12] [13]
Con el lanzamiento de .NET Framework 3.0, Microsoft lanzó una segunda API paralela para renderizar GUI: Windows Presentation Foundation (WPF) basada en DirectX, [14] junto con un lenguaje declarativo de GUI llamado XAML . [15]
Durante una sesión de preguntas y respuestas en la Conferencia Build 2014 , Microsoft explicó que Windows Forms estaba en modo de mantenimiento, sin que se agregaran nuevas características, pero que los errores encontrados se solucionarían de todos modos. [16] Más recientemente, se introdujo un soporte mejorado de alto DPI para varios controles de Windows Forms en las actualizaciones de la versión 4.5 de .NET Framework. [17]
Para el desarrollo futuro, Microsoft ha reemplazado a Windows Forms con una entrada de interfaz gráfica de usuario basada en XAML que utiliza marcos como WPF y UWP . Sin embargo, la colocación de componentes de interfaz gráfica de usuario mediante arrastrar y soltar de una manera similar a Windows Forms todavía se proporciona en XAML al reemplazar el elemento XAML raíz de la página/ventana con un control de interfaz de usuario "Canvas". Al realizar este cambio, el usuario puede crear una ventana de una manera similar a la de Windows Forms al arrastrar y soltar componentes directamente mediante la interfaz gráfica de usuario de Visual Studio.
Si bien XAML ofrece compatibilidad con versiones anteriores mediante la función de arrastrar y soltar a través del control Canvas, los controles XAML solo son similares a los controles de Windows Forms y no son compatibles con versiones anteriores en su totalidad. Realizan funciones similares y tienen una apariencia similar, pero las propiedades y los métodos son lo suficientemente diferentes como para requerir la reasignación de una API a otra.
Mono es un proyecto liderado por Xamarin (anteriormente por Ximian , luego por Novell ) para crear un conjunto de herramientas compatible con .NET Framework y compatible con el estándar Ecma .
En 2011, se anunció que el soporte de Mono para System.Windows.Forms a partir de .NET 2.0 era completo; [18] System.Windows.Forms 2.0 funciona de forma nativa en Mac OS X. [19] Sin embargo, System.Windows.Forms no se ha desarrollado activamente en Mono. [20] La compatibilidad total con .NET no fue posible, porque System.Windows.Forms de Microsoft es principalmente un contenedor alrededor de la API de Windows , y algunos de los métodos permiten el acceso directo a las devoluciones de llamadas de Win32 , que no están disponibles en plataformas distintas de Windows. [11] Un problema más significativo es que, desde la versión 5.2, [21] Mono se ha actualizado para que su valor predeterminado sea asumir una plataforma de 64 bits. Sin embargo, System.Windows.Forms en Mono para la plataforma Macintosh OS X se ha creado utilizando un subsistema de 32 bits, Carbon . [22] A partir de esta fecha [ ¿ cuándo? ] , una versión de 64 bits de System.Windows.Forms para usar en Mac OS X sigue sin estar disponible y solo se puede esperar que se ejecuten aplicaciones .NET creadas para la plataforma de 32 bits.
Es muy poco probable que la implementación implemente alguna vez todo lo necesario para una compatibilidad total con Windows.Forms. La razón es que Windows.Forms no es un conjunto de herramientas completo y, para solucionar este problema, se expone al programador parte de la base subyacente de Win32 mediante la exposición del controlador de mensajes de Windows.
WPF no pretende reemplazar a Windows Forms. [...] Windows Forms sigue vigente y Microsoft seguirá mejorando y dándole soporte durante los próximos años. WPF es simplemente otra herramienta que los desarrolladores de aplicaciones de escritorio de Windows pueden usar cuando sea apropiado.
Windows Forms sigue recibiendo soporte, pero en modo de mantenimiento. Se solucionarán los errores a medida que se descubran, pero no se prevén nuevas funciones.
El soporte para Windows Forms 2.0 está completo. En este momento, estamos básicamente solucionando errores y puliendo nuestro código.
¿Winforms funciona en OSX? Sí, a partir de Mono 1.9, Winforms tiene un controlador nativo de OSX que utiliza de forma predeterminada
utilice Windows.Forms, teniendo en cuenta que puede ser necesario corregir errores o hacer alguna solución alternativa por parte de ellos, ya que nuestro Windows.Forms no se desarrolla activamente.