Windows Forms

Da Wikipedia, l'enciclopedia libera.
Vai alla navigazione Vai alla ricerca

Microsoft Windows Forms è il nome dato alla parte di GUI del framework Microsoft.NET, fornisce accesso al widgets nativo di Windows incapsulando l'esistente Win32 API in modalità managed code.

Anche se Microsoft Windows Forms è visto come un sostituto per il precedente e più complesso sistema Microsoft Foundation Classes basato su C++, non offre caratteristiche paragonabili, come ad esempio l'architettura "Vista/Documento" Model-View-Controller[1][2][3].

L'implementazione esiste all'interno del namespace System.Windows.Forms del framework.NET e cerca correttamente theme itself on Windows XP. Ci sono comunque significanti controversie con questo supporto riguardo ai tab sheets e i controlli piazzati in questi sheets.

Il 4 dicembre 2018, durante la conferenza Microsoft Connect(); 2018, l'azienda ha reso open source Windows Presentation Foundation, Windows Forms e WinUI (Windows UI XAML Library), caricando su GitHub il codice sorgente[4][5][6].

Altri toolkits di GUI per.NET includono:

Architettura[modifica | modifica wikitesto]

Questa API fa parte di .NET Framework 3.0
Questa API fa parte di.NET Framework 3.0

Un'applicazione Windows Form è un'applicazione basata su eventi supportata da.NET Framework di Microsoft. A differenza di un programma batch, trascorre la maggior parte del tempo semplicemente aspettando che l'utente faccia qualcosa, come riempire una casella di testo o fare clic su un pulsante.

Windows Forms fornisce l'accesso ai controlli comuni dell'interfaccia utente di Windows nativi racchiudendo l'API di Windows esistente nel codice gestito[7]. Con l'aiuto di Windows Form,.NET Framework fornisce un'astrazione più completa sopra l'API Win32 rispetto a Visual Basic o MFC[8].

Windows Forms è simile alla libreria MFC (Microsoft Foundation Class) nello sviluppo di applicazioni client. Fornisce un wrapper costituito da un insieme di classi C++ per lo sviluppo di applicazioni Windows. Tuttavia, non fornisce un framework dell'applicazione predefinito come MFC. Ogni controllo in un'applicazione Windows Form è un'istanza concreta di una classe.

Caratteristiche[modifica | modifica wikitesto]

Tutti gli elementi visivi nella libreria di classi Windows Form derivano dalla classe Control. Ciò fornisce la funzionalità minima di un elemento dell'interfaccia utente come posizione, dimensione, colore, carattere, testo, nonché eventi comuni come il clic e il trascinamento/rilascio. La classe Control ha anche il supporto di aggancio per consentire a un controllo di riorganizzare la sua posizione sotto il suo genitore. Il supporto di Microsoft Active Accessibility nella classe Control consente inoltre agli utenti con problemi di utilizzo di utilizzare meglio Windows Form[9].

Oltre a fornire l'accesso ai controlli nativi di Windows come pulsante, casella di testo, casella di controllo e visualizzazione elenco, Windows Forms ha aggiunto i propri controlli per l'hosting ActiveX, la disposizione del layout, la convalida e l'associazione di dati avanzati. Questi controlli vengono visualizzati utilizzando GDI +[9].

Storia e futuro[modifica | modifica wikitesto]

Proprio come Abstract Window Toolkit (AWT), l'equivalente API Java, Windows Forms era un modo semplice e precoce per fornire componenti dell'interfaccia utente grafica a.NET Framework. Windows Forms si basa sull'API di Windows esistente e alcuni controlli si limitano a racchiudere i componenti di Windows sottostanti. Alcuni metodi consentono l'accesso diretto ai callback Win32, che non sono disponibili nelle piattaforme non Windows[10].

In.NET Framework 2.0, Windows Form ha ottenuto controlli di layout più ricchi, controlli toolstrip in stile Office 2003, componente multithreading, supporto per la fase di progettazione e data binding più ricco, nonché ClickOnce per la distribuzione basata sul Web[11][12].

Con il rilascio di.NET 3.0, Microsoft ha rilasciato una seconda API parallela per il rendering delle GUI: Windows Presentation Foundation (WPF) basata su DirectX[13], insieme a un linguaggio dichiarativo della GUI chiamato XAML[14].

Durante una sessione di domande e risposte alla conferenza Build 2014, Microsoft ha spiegato che Windows Forms era in modalità di manutenzione, senza l'aggiunta di nuove funzionalità, ma i bug trovati sarebbero comunque stati risolti[15]. Più recentemente, negli aggiornamenti a.NET Framework versione 4.5 è stato introdotto un supporto migliorato per DPI elevati per vari controlli Windows Forms[16].

Compatibilità con le versioni precedenti di XAML con Windows Form[modifica | modifica wikitesto]

Per lo sviluppo futuro, Microsoft ha sostituito Windows Forms con una voce GUI basata su XAML utilizzando framework come WPF e UWP. Tuttavia, il posizionamento del trascinamento della selezione dei componenti della GUI in modo simile a Windows Forms è ancora fornito in XAML sostituendo l'elemento XAML radice della pagina/finestra con un controllo dell'interfaccia utente "Canvas". Quando apporta questa modifica, l'utente può creare una finestra in modo simile a Windows Forms trascinando e rilasciando direttamente i componenti utilizzando la GUI di Visual Studio.

Sebbene XAML fornisca la compatibilità con le versioni precedenti del posizionamento mediante trascinamento tramite il controllo Canvas, i controlli XAML sono simili solo ai controlli Windows Form e non sono compatibili con le versioni precedenti uno a uno. Eseguono funzioni simili e hanno un aspetto simile, ma le proprietà e i metodi sono abbastanza diversi da richiedere la ri-mappatura da un'API all'altra.

Implementazione alternativa[modifica | modifica wikitesto]

Mono è un progetto guidato da Xamarin (in precedenza Ximian, poi Novell) per creare un set di strumenti compatibile con.NET conforme allo standard Ecma.

Nel 2011, il supporto di Mono per System.Windows.Forms a partire da .NET 2.0 è stato annunciato come completo; System.Windows.Forms 2.0 funziona in modo nativo su Mac OS X[17]. Tuttavia, System.Windows.Forms non è stato sviluppato attivamente su Mono. Piena compatibilità con .NET non era possibile, perché System.Windows.Forms di Microsoft è principalmente un wrapper dell'API di Windows e alcuni metodi consentono l'accesso diretto ai callback Win32, che non sono disponibili su piattaforme diverse da Windows[10]. Un problema più significativo è che, dalla versione 5.2[18], Mono è stato aggiornato in modo che il suo valore predefinito presupponga una piattaforma a 64 bit. Tuttavia, System.Windows.Forms su Mono per la piattaforma Macintosh OS X è stato creato utilizzando un sottosistema a 32 bit, Carbon[19].

Note[modifica | modifica wikitesto]

  1. ^ Design and Implementation Guidelines for Web Clients by Microsoft Pattern and Practices, su msdn.microsoft.com, Microsoft, novembre 2003.
  2. ^ Chris Sells e Michael Weinhardt, Appendix B, in Moving from MFC, Windows Forms 2.0 Programming, 2nd, Addison-Wesley Professional, 16 maggio 2006.
  3. ^ Introduction to Windows Forms, su msdn.microsoft.com, Microsoft 2003.
  4. ^ Microsoft rende Windows Forms, WinUI e WPF open source, su Hardware Upgrade. URL consultato il 5 dicembre 2018.
  5. ^ Jeff Martin, Microsoft Open Sources WPF, WinForms, and WinUI, in InfoQ, 4 dicembre 2018. URL consultato il 6 dicembre 2018.
  6. ^ Scott Hanselman, Announcing WPF, WinForms, and WinUI are going Open Source, su hanselman.com, 4 dicembre 2018. URL consultato il 6 dicembre 2018.
  7. ^ Bart De Smet, Chapter 5, in C# 4.0 Unleashed, Sams Publishing, 4 gennaio 2011.
  8. ^ Ian Griffiths e Matthew Adams, NET Windows Forms in a Nutshell, O'Reilly Media, marzo 2003, p. 4.
  9. ^ a b Ian Griffiths e Matthew Adams, NET Windows Forms in a Nutshell, O'Reilly Media, marzo 2003, pp. 27–53.
  10. ^ a b FAQ: Winforms, su mono-project.com.
    «It is very unlikely that the implementation will ever implement everything needed for full compatibility with Windows.Forms. The reason is that Windows.Forms is not a complete toolkit, and to work around this problem some of the underlying Win32 foundation is exposed to the programmer in the form of exposing the Windows message handler»
  11. ^ Chris Sells e Michael Weinhardt, Appendix A. What s New in Windows Forms 2.0, in Windows Forms 2.0 Programming, 2nd, Addison-Wesley Professional, 16 maggio 2006.
  12. ^ Brian Noyes, Preface, in Data Binding with Windows Forms 2.0: Programming Smart Client Data Applications with .NET, 1st, Addison-Wesley Professional, 12 gennaio 2006.
  13. ^ Gary Hall, DirectX, not GDI+, in Pro WPF and Silverlight MVVM: Effective Application Development with Model, 2010ª ed., Apress, 27 dicembre 2010, p. 2.
  14. ^ Josh Smith, WPF vs. Windows Forms, su joshsmithonwpf.wordpress.com, Josh Smith on WPF, 5 settembre 2007. URL consultato il 25 agosto 2011.
    «WPF is not intended to replace Windows Forms. [...] Windows Forms is still alive and well, and will continue to be enhanced and supported by Microsoft for years to come. WPF is simply another tool for Windows desktop application developers to use, when appropriate.»
  15. ^ A WPF Q&A, su infoq.com, 3 aprile 2014. URL consultato il 21 aprile 2014.
    «Windows Forms is continuing to be supported, but in maintenance mode. They will fix bugs as they are discovered, but new functionality is off the table»
  16. ^ Jonathan Allen, High DPI Improvements for Windows Forms in .NET 4.5.2, su InfoQ, 6 maggio 2014. URL consultato il 10 febbraio 2015.
  17. ^ WinForms, su mono-project.com. URL consultato il 30 luglio 2011.
    «Does Winforms run on OSX? Yes, as of Mono 1.9, Winforms has a native OSX driver that it uses by default»
  18. ^ Introduction to Mono on macOS, su mono-project.com. URL consultato il 12 novembre 2019.
  19. ^ Jess Martin, Windows.Forms Comes to 64-bit Mac OS X, su infoq.com. URL consultato il 12 novembre 2019.

Voci correlate[modifica | modifica wikitesto]

Collegamenti esterni[modifica | modifica wikitesto]

Estratto da "https://it.wikipedia.org/w/index.php?title=Windows_Forms&oldid=130511640"