Для чего предназначен windows forms designer платформы net

From Wikipedia, the free encyclopedia

This article needs to be updated. Please help update this article to reflect recent events or newly available information. (January 2023)

Windows Forms (WinForms)


Other names	WinForms
Original author(s)	.NET: Microsoft, Mono: Ximian/Novell
Developer(s)	.NET Foundation
Initial release	February 13, 2002; 20 years ago
Stable release	v5.0.17 / May 11, 2022; 8 months ago
Repository	github.com/dotnet/winforms
Written in	C#
Operating system	Microsoft Windows
Platform	.NET Framework, .NET, Mono
Type	Software framework
License	MIT License
Website	docs.microsoft.com/en-us/dotnet/framework/winforms/

Windows Forms (WinForms) is a free and open-source graphical (GUI) class library included as a part of Microsoft .NET, .NET Framework or Mono,^[1] providing a platform to write client applications for desktop, laptop, and tablet PCs.^[2] While it is seen as a replacement for the earlier and more complex C++ based Microsoft Foundation Class Library, it does not offer a comparable paradigm^[3] and only acts as a platform for the user interface tier in a multi-tier solution.^[4]

At the Microsoft Connect event on December 4, 2018, Microsoft announced releasing Windows Forms as an open source project on GitHub. It is released under the MIT License. With this release, Windows Forms has become available for projects targeting the .NET Core framework. However, the framework is still available only on the Windows platform, and Mono’s incomplete implementation of Windows Forms remains the only cross-platform implementation.^[5]^[6]

Architecture[edit]

A Windows Forms application is an event-driven application supported by Microsoft’s .NET Framework. Unlike a batch program, it spends most of its time simply waiting for the user to do something, such as fill in a text box or click a button. The code for the application can be written in a .NET programming language such as C# or Visual Basic.

Windows Forms provides access to native Windows User Interface Common Controls by wrapping the existent Windows API in managed code.^[7] With the help of Windows Forms, the .NET Framework provides a more comprehensive abstraction above the Win32 API than Visual Basic or MFC did.^[8]

Windows Forms is similar to Microsoft Foundation Class (MFC) library in developing client applications. It provides a wrapper consisting of a set of C++ classes for development of Windows applications. However, it does not provide a default application framework like the MFC. Every control in a Windows Forms application is a concrete instance of a class.

Features[edit]

All visual elements in the Windows Forms class library derive from the Control class. This provides the minimal functionality of a user interface element such as location, size, color, font, text, as well as common events like click and drag/drop. The Control class also has docking support to let a control rearrange its position under its parent. The Microsoft Active Accessibility support in the Control class also helps impaired users to use Windows Forms better.^[9]

In Visual Studio, forms are created using drag-and-drop techniques. A tool is used to place controls (e.g., text boxes, buttons, etc.) on the form (window). Controls have attributes and event handlers associated with them. Default values are provided when the control is created, but may be changed by the programmer. Many attribute values can be modified during run time based on user actions or changes in the environment, providing a dynamic application. For example, code can be inserted into the form resize event handler to reposition a control so that it remains centered on the form, expands to fill up the form, etc. By inserting code into the event handler for a keypress in a text box, the program can automatically translate the case of the text being entered, or even prevent certain characters from being inserted.

Besides providing access to native Windows controls like button, textbox, checkbox and listview, Windows Forms added its own controls for ActiveX hosting, layout arrangement, validation and rich data binding. Those controls are rendered using GDI+.^[9]

History and future[edit]

Just like Abstract Window Toolkit (AWT), the equivalent Java API, Windows Forms was an early and easy way to provide graphical user interface components to the .NET Framework. Windows Forms is built on the existing Windows API and some controls merely wrap underlying Windows components.^[10] Some of the methods allow direct access to Win32 callbacks, which are not available in non-Windows platforms.^[10]

In .NET Framework 2.0, Windows Forms gained richer layout controls, Office 2003 style toolstrip controls, multithreading component, richer design-time and data binding support as well as ClickOnce for web-based deployment.^[11]^[12]

With the release of .NET 3.0, Microsoft released a second, parallel API for rendering GUIs: Windows Presentation Foundation (WPF) based on DirectX,^[13] together with a GUI declarative language called XAML.^[14]

During a question-and-answer session at the Build 2014 Conference, Microsoft explained that Windows Forms was under maintenance mode, with no new features being added, but bugs found would still be fixed.^[15] Most recently, improved high-DPI support for various Windows Forms controls was introduced in updates to .NET Framework version 4.5.^[16]

XAML backwards compatibility with Windows Forms[edit]

For future development, Microsoft has succeeded Windows Forms with an XAML-based GUI entry using frameworks such as WPF and UWP. However, drag and drop placement of GUI components in a manner similar to Windows Forms is still provided in XAML by replacing the root XAML element of the Page/Window with a «Canvas» UI-Control. When making this change, the user can build a window in a similar fashion as in Windows Forms by directly dragging and dropping components using the Visual Studio GUI.

While XAML provides drag and drop placement backwards compatibility through the Canvas Control, XAML Controls are only similar to Windows Forms Controls and are not one-to-one backwards compatible. They perform similar functions and have a similar appearance, but the properties and methods are different enough to require remapping from one API to another.

Alternative implementation[edit]

Mono is a project led by Xamarin (formerly by Ximian, then Novell) to create an Ecma standard compliant .NET Framework compatible set of tools.

In 2011, Mono’s support for System.Windows.Forms as of .NET 2.0 was announced as complete;^[17]
System.Windows.Forms 2.0 works natively on Mac OS X.^[18]
However, System.Windows.Forms has not been actively developed on Mono.^[19]
Full compatibility with .NET was not possible, because Microsoft’s System.Windows Forms is mainly a wrapper around the Windows API, and some of the methods allow direct access to Win32 callbacks, which are not available in platforms other than Windows.^[10]
A more significant problem is that, since version 5.2,^[20]
Mono has been upgraded so that its default is to assume a 64 bit platform.
However, System.Windows.Forms on Mono for the Macintosh OS X platform has been built using a 32 bit subsystem, Carbon.^[21]
As of this date^[when?], a 64-bit version of System.Windows.Forms for use on Mac OS X remains unavailable and only .NET applications built for the 32 bit platform can be expected to execute.

References[edit]

^ Sells, Chris (September 6, 2003). Windows Forms Programming in C# (1st ed.). Addison-Wesley Professional. p. xxxviiii.
^ «Design and Implementation Guidelines for Web Clients by Microsoft Pattern and Practices». Microsoft. November 2003.
^ Sells, Chris; Weinhardt, Michael (May 16, 2006). «Appendix B». Moving from MFC, Windows Forms 2.0 Programming (2nd ed.). Addison-Wesley Professional.
^ «Introduction to Windows Forms» (Visual Studio 2003 documentation). Microsoft 2003.
^ Martin, Jeff (4 December 2018). «Microsoft Open Sources WPF, WinForms, and WinUI». InfoQ. Retrieved 2018-12-06.
^ Hanselman, Scott (4 December 2018). «Announcing WPF, WinForms, and WinUI are going Open Source». Retrieved 2018-12-06.
^ De Smet, Bart (January 4, 2011). «Chapter 5». C# 4.0 Unleashed. Sams Publishing.
^ Griffiths, Ian; Adams, Matthew (March 2003). NET Windows Forms in a Nutshell. O’Reilly Media. p. 4.
^ ^a ^b Griffiths, Ian; Adams, Matthew (March 2003). NET Windows Forms in a Nutshell. O’Reilly Media. pp. 27–53.
^ ^a ^b ^c «FAQ: Winforms». 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
^ Sells, Chris; Weinhardt, Michael (May 16, 2006). «Appendix A. What s New in Windows Forms 2.0». Windows Forms 2.0 Programming (2nd ed.). Addison-Wesley Professional.
^ Noyes, Brian (January 12, 2006). «Preface». Data Binding with Windows Forms 2.0: Programming Smart Client Data Applications with .NET (1st ed.). Addison-Wesley Professional.
^ Hall, Gary (December 27, 2010). «DirectX, not GDI+». Pro WPF and Silverlight MVVM: Effective Application Development with Model (2010 ed.). Apress. p. 2.
^ Smith, Josh (2007-09-05). «WPF vs. Windows Forms». Josh Smith on WPF. Retrieved 2011-08-25. 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.
^ «A WPF Q&A». infoq.com. 2014-04-03. Retrieved 2014-04-21. 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
^ Allen, Jonathan (2014-05-06). «High DPI Improvements for Windows Forms in .NET 4.5.2». InfoQ. Retrieved 2015-02-10.
^ «WinForms». mono-project.com. Retrieved 2011-07-30. Support for Windows Forms 2.0 is complete. At this point, we are largely just fixing bugs and polishing our code.
^ «WinForms». mono-project.com. Retrieved 2011-07-30. Does Winforms run on OSX? Yes, as of Mono 1.9, Winforms has a native OSX driver that it uses by default
^ de Icaza, Miguel (2011-03-07). «GDC 2011». Retrieved 2011-07-30. For tools that are mostly OpenGL/DirectX based, use Windows.Forms, keeping in mind that some bug fixing or work around on their part might be needed as our Windows.Forms is not actively developed.
^ «Introduction to Mono on macOS». mono-project.com. Retrieved 2019-11-12.
^ Martin, Jess. «Windows.Forms Comes to 64-bit Mac OS X». Retrieved 2019-11-12.

External links[edit]

MSDN: Building Windows Forms applications
MSDN : Windows.Forms reference documentation
MSDN : Windows Forms Technical Articles — Automating Windows Form with Visual Test

Источник

From Wikipedia, the free encyclopedia

This article needs to be updated. Please help update this article to reflect recent events or newly available information. (January 2023)

Windows Forms (WinForms)


Other names	WinForms
Original author(s)	.NET: Microsoft, Mono: Ximian/Novell
Developer(s)	.NET Foundation
Initial release	February 13, 2002; 20 years ago
Stable release	v5.0.17 / May 11, 2022; 8 months ago
Repository	github.com/dotnet/winforms
Written in	C#
Operating system	Microsoft Windows
Platform	.NET Framework, .NET, Mono
Type	Software framework
License	MIT License
Website	docs.microsoft.com/en-us/dotnet/framework/winforms/

Architecture[edit]

Features[edit]

History and future[edit]

XAML backwards compatibility with Windows Forms[edit]

Alternative implementation[edit]

Mono is a project led by Xamarin (formerly by Ximian, then Novell) to create an Ecma standard compliant .NET Framework compatible set of tools.

References[edit]

^ Sells, Chris (September 6, 2003). Windows Forms Programming in C# (1st ed.). Addison-Wesley Professional. p. xxxviiii.
^ «Design and Implementation Guidelines for Web Clients by Microsoft Pattern and Practices». Microsoft. November 2003.
^ Sells, Chris; Weinhardt, Michael (May 16, 2006). «Appendix B». Moving from MFC, Windows Forms 2.0 Programming (2nd ed.). Addison-Wesley Professional.
^ «Introduction to Windows Forms» (Visual Studio 2003 documentation). Microsoft 2003.
^ Martin, Jeff (4 December 2018). «Microsoft Open Sources WPF, WinForms, and WinUI». InfoQ. Retrieved 2018-12-06.
^ Hanselman, Scott (4 December 2018). «Announcing WPF, WinForms, and WinUI are going Open Source». Retrieved 2018-12-06.
^ De Smet, Bart (January 4, 2011). «Chapter 5». C# 4.0 Unleashed. Sams Publishing.
^ Griffiths, Ian; Adams, Matthew (March 2003). NET Windows Forms in a Nutshell. O’Reilly Media. p. 4.
^ ^a ^b Griffiths, Ian; Adams, Matthew (March 2003). NET Windows Forms in a Nutshell. O’Reilly Media. pp. 27–53.
^ ^a ^b ^c «FAQ: Winforms». 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
^ Sells, Chris; Weinhardt, Michael (May 16, 2006). «Appendix A. What s New in Windows Forms 2.0». Windows Forms 2.0 Programming (2nd ed.). Addison-Wesley Professional.
^ Noyes, Brian (January 12, 2006). «Preface». Data Binding with Windows Forms 2.0: Programming Smart Client Data Applications with .NET (1st ed.). Addison-Wesley Professional.
^ Hall, Gary (December 27, 2010). «DirectX, not GDI+». Pro WPF and Silverlight MVVM: Effective Application Development with Model (2010 ed.). Apress. p. 2.
^ Smith, Josh (2007-09-05). «WPF vs. Windows Forms». Josh Smith on WPF. Retrieved 2011-08-25. 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.
^ «A WPF Q&A». infoq.com. 2014-04-03. Retrieved 2014-04-21. 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
^ Allen, Jonathan (2014-05-06). «High DPI Improvements for Windows Forms in .NET 4.5.2». InfoQ. Retrieved 2015-02-10.
^ «WinForms». mono-project.com. Retrieved 2011-07-30. Support for Windows Forms 2.0 is complete. At this point, we are largely just fixing bugs and polishing our code.
^ «WinForms». mono-project.com. Retrieved 2011-07-30. Does Winforms run on OSX? Yes, as of Mono 1.9, Winforms has a native OSX driver that it uses by default
^ de Icaza, Miguel (2011-03-07). «GDC 2011». Retrieved 2011-07-30. For tools that are mostly OpenGL/DirectX based, use Windows.Forms, keeping in mind that some bug fixing or work around on their part might be needed as our Windows.Forms is not actively developed.
^ «Introduction to Mono on macOS». mono-project.com. Retrieved 2019-11-12.
^ Martin, Jess. «Windows.Forms Comes to 64-bit Mac OS X». Retrieved 2019-11-12.

External links[edit]

MSDN: Building Windows Forms applications
MSDN : Windows.Forms reference documentation
MSDN : Windows Forms Technical Articles — Automating Windows Form with Visual Test

Источник

Windows Forms

За последние несколько лет Web-ориентированные приложения стали чрезвычайно популярными. Возможность размещать всю логику приложений на централизованном сервере выглядит очень привлекательной с точки зрения администратора. Развертывание программного обеспечения, базирующегося на клиенте, очень трудно, особенно, если оно основано на COM-объектах. Недостаток Web-ориентированных приложений состоит в том, что они не могут предоставить достаточно богатых возможностей пользователю.

Платформа .NET Framework позволяет разрабатывать интеллектуальные клиентские приложения с богатыми возможностями, при этом избегая проблем с развертыванием и “DLL-адом”, как это было раньше. Независимо от того, что будет выбрано — Windows Forms или Windows Presentation Foundation (см. главу 34) — разработка или развертывание клиентских приложений теперь не представляет особой сложности.

Windows Forms уже оказал влияние на разработки для Windows. Теперь, когда приложение находится на начальной стадии проектирования, принять решение о том, нужно ли строить Web-ориентированное приложение либо же полностью клиентское, стало немного труднее. Клиентские приложения Windows могут быть разработаны быстро и эффективно, при этом они предлагают пользователям гораздо более широкие возможности.

Windows Forms покажется вам знакомым, если у вас есть опыт разработки на Visual Basic. Вы создаете новые формы (также известные как окна или диалоги) в той же манере — перетаскивая и размещая элементы управления из панели инструментов на поверхность визуального дизайнера форм (Form Designer). Однако если ваш опыт в основном касается классического стиля языка C для Windows-программирования, где приходилось создавать конвейеры сообщений и отслеживать эти сообщения, или же если вы — программист, применяющий MFC, то в этом случае вы обнаружите, что и здесь при необходимости у вас есть возможность работать с низкоуровневыми деталями. Вы можете переопределить оконную процедуру (WndProc) и перехватывать сообщения, но в действительности вас удивит, что делать это придется нечасто.

В этой главе мы рассмотрим следующие аспекты Windows Forms:

класс Form;

иерархия классов Windows Forms;

элементы управления и компоненты, являющиеся частью пространства имен

System.Windows.Forms;

меню и панели инструментов;

создание элементов управления;

создание пользовательских элементов управления.

Глава 31. Windows Forms 1055

Создание приложения Windows Forms

Первое, что необходимо сделать — создать приложение Windows Forms. Для примера создадим пустую форму и отобразим ее на экране. При разработке этого примера мы не будем использовать Visual Studio .NET. Наберем его в текстовом редакторе и соберем с помощью компилятора командной строки. Ниже показан код примера.

using System;

using System.Windows.Forms; namespace NotepadForms

{

public class MyForm : System.Windows.Forms.Form

{

public MyForm()

{

}

[STAThread] static void Main()

{

Application.Run(new MyForm());

}

Когда мы скомпилируем и запустим этот пример, то получим маленькую пустую форму без заголовка. Никаких реальных функций, но это — Windows Forms.

В приведенном коде заслуживают внимания две вещи. Первая — тот факт, что при создании класса MyForm используется наследование. Следующая строка объявляет

MyForm как наследника System.Windows.Forms.Form:

public class MyForm : System.Windows.Forms.Form

Класс Form — один из главных классов в пространстве имен System.Windows.Forms. Следующий фрагмент кода стоит рассмотреть более подробно:

[STAThread] static void Main()

{

Application.Run(new MyForm());

}

Main — точка входа по умолчанию в любое клиентское приложение на C#. Как правило, в более крупных приложениях метод Main() не будет находиться в классе формы, а скорее в классе, отвечающем за процесс запуска. В данном случае вы должны установить имя такого запускающего класса в диалоговом окне свойств проекта. Обратите внимание на атрибут [STAThread]. Он устанавливает модель многопоточности COM в STA (однопоточный апартамент). Модель многопоточности STA требуется для взаимодействия с COM и устанавливается по умолчанию в каждом проекте Windows Forms.

Метод Application.Run() отвечает за запуск стандартного цикла сообщений приложения. Application.Run() имеет три перегрузки.

Первая из них не принимает параметров; вторая принимает в качестве параметра объект ApplicationContext. В нашем примере объект MyForm становится главной формой приложения. Это означает, что когда форма закрывается, то приложение завершается. Используя класс ApplicationContext, можно в большей степени контролировать завершение главного цикла сообщений и выход из приложения.

1056 Часть V. Презентации

Класс Application содержит в себе очень полезную функциональность. Он предоставляет группу статических методов и свойств для управления процессом запуска и останова приложения, а также обеспечивает доступ к сообщениям Windows, обрабатываемым приложением. В табл. 31.1 перечислены некоторые из этих наиболее полезных методов и свойств.

Таблица 31.1. Некоторые полезные методы и свойства класса Application

Метод/свойство	Описание
CommonAppDataPath	Путь к данным, общий для всех пользователей приложения. Обычно
	это БазовыйПутьНазвание компанииНазвание продуктаВерсия,
	где БазовыйПуть — C:Documents and Settingsимя пользователя
ExecutablePath	ApplicationData. Если путь не существует, он будет создан.
Путь и имя исполняемого файла, запускающего приложение.
LocalUserAppDataPath	Подобно	, но с тем отличием, что поддерживается
		CommonAppDataPath
	роуминг (перемещаемость).
MessageLoop	True или false — в зависимости от того, существует ли цикл сообще-
StartupPath	ний в текущем потоке.
Подобно	, с тем отличием, что имя файла не возвра-
	щается.	ExecutablePath

AddMessageFilter	Используется для предварительной обработки сообщений. Объект,
	реализующий IMessageFilter, позволяет фильтровать сообщения в
	цикле или организовать специальную обработку, выполняемую перед
	тем, как сообщение попадет в цикл.
DoEvents	Аналогично оператору DoEvents языка Visual Basic. Позволяет обрабо-
	тать сообщения в очереди.
EnableVisualStyles	Обеспечивает визуальный стиль Windows XP для различных визуальных
	элементов приложения. Существуют две перегрузки, принимающие
	информацию манифеста. Одна работает с потоком манифеста, вто-
	рая — принимает полное имя и путь файла манифеста.
Exit и ExitThread	Exit завершает текущий работающий цикл сообщений и вызывает вы-
	ход из приложения. ExitThread завершает цикл сообщений и закры-
	вает все окна текущего потока.

А теперь как будет выглядеть это приложение, если его сгенерировать в Visual Studio 2008? Первое, что следует отметить — будет создано два файла. Причина в том, что Visual Studio 2008 использует возможность частичных (partial) классов и выделяет весь код, сгенерированный визуальным дизайнером, в отдельный файл. Если используется имя по умолчанию — Form1, то эти два файла будет называться Form1.cs и Form1.Designer.cs. Если только у вас не включена опция Show All Files (Показать все файлы) в меню Project (Проект), то вы не увидите в проводнике Solution Explorer файла Form1.Designer.cs. Ниже показан код этих двух файлов, сгенерированных Visual Studio. Сначала — Form1.cs:

using System;

using System.Collections.Generic; using System.ComponentModel; using System.Data;

using System.Drawing; using System.Linq; using System.Text;

Глава 31. Windows Forms 1057

using System.Windows.Forms;

namespace VisualStudioForm

{

public partial class Form1 : Form

{

public Form1()

{

InitializeComponent();

}

Здесь мы видим только операторы using и простой конструктор. А вот код Form1. Designer.cs:

namespace VisualStudioForm

{

partial class Form1

{

///<summary>

///Required designer variable.

///</summary>

private System.ComponentModel.IContainer components = null;

///<summary>

///Clean up any resources being used.

///</summary>

///< param name=»disposing» > true if managed resources should be disposed; otherwise, false. < /param >

protected override void Dispose(bool disposing)

{

if (disposing && (components != null))

{

components.Dispose();

}

base.Dispose(disposing);

}

#region Windows Form Designer generated code

///<summary>

///Required method for Designer support — do not modify

///the contents of this method with the code editor.

///</summary>

private void InitializeComponent()

{

this.components = new System.ComponentModel.Container(); this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font; this.Text = «Form1»;

}

#endregion

}

Файл, сгенерированный дизайнером форм, редко подвергается ручному редактированию. Единственным исключением может быть случай, когда необходима специальная обработка в методе Dispose(). Метод InitializeComponent мы обсудим позднее в этой главе.

Если взглянуть на этот код примера приложения в целом, то мы увидим, что он намного длиннее, чем простой пример командной строки. Здесь перед началом класса присутствует несколько операторов using, и большинство из них в данном примере не нужны. Однако их присутствие ничем не мешает. Класс Form1 наследуется от

1058 Часть V. Презентации

System.Windows.Forms.Form, как и в предыдущем, введенном в Notepad примере, но в этой точке начинаются расхождения. Во-первых, в файле Form1.Designer появляется строка:

private System.ComponentModel.IContainer components = null;

В данном примере эта строка кода ничего не делает. Но, добавляя компонент в форму, вы можете также добавить его в объект components, который представляет собой контейнер. Причина добавления этого контейнера — в необходимости правильной обработки уничтожения формы. Класс формы поддерживает интерфейс IDisposable, потому что он реализован в классе Component. Когда компонент добавляется в контейнер, то этот контейнер должен позаботиться о корректном уничтожении своего содержимого при закрытии формы. Это можно увидеть в методе Dispose нашего примера:

protected override void Dispose(bool disposing)

{

if (disposing && (components != null))

{

components.Dispose();

}

base.Dispose(disposing);

}

Здесь мы видим, что когда вызывается метод Dispose формы, то также вызывается метод Dispose объекта components, поскольку он содержит в себе другие компоненты, которые также должны быть корректно удалены.

Конструктор класса Form1, находящийся в файле Form1.cs, выглядит так:

public Form1()

{

InitializeComponent();

}

Обратите внимание на вызов InitializeComponent().

Метод InitializeComponent() находится в файле Form1.Designer.cs и делает то, что следует из его наименования — инициализирует все элементы управления, которые могут быть добавлены к форме. Он также инициализирует свойства формы.

В нашем примере метод InitializeComponent() выглядит следующим образом:

private void InitializeComponent()

{

this.components = new System.ComponentModel.Container(); this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font; this.Text = «Form1»;

}

Как видите, здесь присутствует лишь базовый код инициализации. Этот метод связан с визуальным дизайнером Visual Studio. Когда в форму вносятся изменения в дизайнере, они отражаются на InitializeComponent(). Если вы вносите любые изменения в InitializeComponent(), то следующий раз после того, как что-то будет изменено в дизайнере, эти ручные изменения будут утеряны. InitializeComponent() повторно генерируется после каждого изменения дизайна формы. Если возникает необходимость добавить некоторый дополнительный код для формы или элементов управления и компонентов формы, это должно быть сделано после вызова InitializeComponent(). Этот метод также отвечает за создание экземпляров элементов управления, поэтому любой вызов, ссылающийся на них, выполненный до InitializeComponent(), завершится возбуждением исключения нулевой ссылки.

Глава 31. Windows Forms 1059

Чтобы добавить элемент управления или компонент в форму, нажмите комбинацию клавиш <Ctrl+Alt+X> или выберите пункт меню View Toolbox (Вид Панель инструментов) в среде Visual Studio .NET. Щелкните правой кнопкой мыши на Form1.cs в проводнике Solution Explorer и в появившемся контекстном меню выберите пункт View Designer (Показать дизайнер). Выберите элемент управления Button и перетащите на поверхность формы в визуальном дизайнере. Можно также дважды щелкнуть на выбранном элементе управления, и он будет добавлен в форму. То же самое следует проделать с элементом TextBox.

Теперь, после добавления этих двух элементов управления на форму, метод InitializeComponent() расширяется и содержит такой код:

private void InitializeComponent()

{

this.button1 = new System.Windows.Forms.Button(); this.textBox1 = new System.Windows.Forms.TextBox(); this.SuspendLayout();

//button1

this.button1.Location = new System.Drawing.Point(77, 137); this.button1.Name = «button1»;

this.button1.Size = new System.Drawing.Size(75, 23); this.button1.TabIndex = 0;

this.button1.Text = «button1»; this.button1.UseVisualStyleBackColor = true;

//textBox1

this.textBox1.Location = new System.Drawing.Point(67, 75); this.textBox1.Name = «textBox1»;

this.textBox1.Size = new System.Drawing.Size(100, 20); this.textBox1.TabIndex = 1;

// Form1

this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F); this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font; this.ClientSize = new System.Drawing.Size(284, 264); this.Controls.Add(this.textBox1); this.Controls.Add(this.button1);

this.Name = «Form1»; this.Text = «Form1»; this.ResumeLayout(false); this.PerformLayout();

}

Если посмотреть на первые три строки кода этого метода, мы увидим в них создание экземпляров элементов управления Button и TextBox. Обратите внимание на имена, присвоенные им — textBox1 и button1. По умолчанию дизайнер в качестве имен использует имя класса элемента управления, дополненное целым числом. Когда вы добавляете следующую кнопку, дизайнер называет ее button2 и т.д. Следующая строка — часть пары SuspendLayout/ResumeLayout. Метод SuspendLayout() временно приостанавливает события размещения, которые имеют место при первоначальной инициализации элемента управления. В конце метода вызывается ResumeLayout(), чтобы вернуть все в норму. В сложной форме с множеством элементов управления метод InitializeComponent() может стать достаточно большим.

1060 Часть V. Презентации

Чтобы изменить значения свойств элемента управления, нужно либо нажать <F4>, либо выбрать пункт меню View Properties Window (Вид Окно свойств). Это окно позволяет модифицировать большинство свойств элемента управления или компонента. При внесении изменений в окне свойств метод InitializeComponent() автоматически переписывается с тем, чтобы отразить новые значения свойств. Например, изменив свойство Text на My Button в окне свойств, получим следующий код в

InitializeComponent():

// button1

this.button1.Location = new System.Drawing.Point(77, 137); this.button1.Name = «button1»;

this.button1.Size = new System.Drawing.Size(75, 23); this.button1.TabIndex = 0;

this.button1.Text = «My Button»; this.button1.UseVisualStyleBackColor = true;

Даже если вы предпочитаете использовать какой-то редактор, отличный от Visual Studio .NET, то наверняка захотите включать функции вроде InitializeComponent() в свои проекты. Сохранение всего кода инициализации в одном месте обеспечит возможность его вызова из каждого конструктора.

Иерархия классов

Важность понимания иерархии становится очевидной в процессе проектирования и конструирования пользовательских элементов управления. Если такой элемент управления унаследован от конкретного библиотечного элемента управления, например, когда создается текстовое поле с некоторыми дополнительными методами и свойствами, то имеет смысл унаследовать его от обычного текстового поля и затем переопределить и добавить необходимые методы. Однако если приходится создавать элемент управления, который не соответствует ни одному из существующих в .NET Framework, то его придется унаследовать от одного из базовых классов: Control или ScrollableControl, если нужны возможности прокрутки, либо ContainerControl, если он должен служить контейнером для других элементов управления.

Остальная часть этой главы посвящена изучению большинства из этих классов — как они работают вместе, и как их можно использовать для построения профессионально выглядящих клиентских приложений.

Класс Control

Пространство имен System.Windows.Forms включает один класс, который является базовым почти для всех элементов управления и форм — System.Windows.Forms. Control. Он реализует основную функциональность для создания экранов, которые видит пользователь. Класс Control унаследован от System.ComponentModel.Component. Класс Component обеспечивает классу Control инфраструктуру, необходимую для того, чтобы его можно было перетаскивать и помещать на поле дизайнера, а также, чтобы он мог включать в себя другие элементы управления. Класс Control предлагает огромный объем функциональности классам, наследуемым от него. Этот список слишком большой, чтобы приводить его здесь, поэтому в данном разделе мы рассмотрим только наиболее важные возможности, предоставляемые классом Control. Позднее в этой главе, когда мы будем рассматривать специфические элементы управления, основанные на Control, мы увидим эти методы и свойства в коде примеров. Следующие

Глава 31. Windows Forms 1061

подразделы группируют методы и свойства по их функциональности, поэтому взаимосвязанные элементы могут быть рассмотрены вместе.

Размер и местоположение

Размер и местоположение элементов управления определяются свойствами Height, Width, Top, Bottom, Left и Right, вместе с дополняющими их Size и Location. Отличие состоит в том, что Height, Width, Top, Bottom, Left и Right принимают одно целое значение. Size принимает значение структуры Size, а Location — значение структуры Point. Структуры Size и Point включают в себя координаты X, Y. Point обычно описывает местоположение, а Size — высоту и ширину объекта. Size и Point определены в пространстве имен System.Drawing. Обе структуры очень похожи в том, что представляют пары координат X, Y, но, кроме того — переопределенные операции, упрощающие сравнения и преобразования. Вы можете, например, складывать вместе две структуры Size. В случае структуры Point операция сложения переопределена таким образом, что можно прибавить к Point структуру Size и получить в результате Point. Это дает эффект прибавления расстояния к местоположению, чтобы получить новое местоположение, что очень удобно для динамического создания форм и элементов управления.

Свойство Bounds возвращает объект Rectangle, представляющий экранную область, занятую элементом управления. Эта область включает полосы прокрутки и заголовка. Rectangle также относится к пространству имен System.Drawing. Свойство ClientSize — структура Size, представляющая клиентскую область элемента управления за вычетом полос прокрутки и заголовка.

Методы PointToClient и PointToScreen — удобные методы преобразования, которые принимают Point и возвращают Point. Метод PointToClient принимает структуру Point, представляющую экранные координаты, и транслирует их в координаты текущего клиентского объекта. Это удобно для операций перетаскивания. Метод PointToScreen выполняет обратную операцию — принимает координаты в клиентском объекте и транслирует их в экранные координаты.

Методы RectangleToScreen и ScreenToRectangle выполняют те же операции, но со структурами Rectangle вместо Point.

Свойство Dock определяет, к какой грани родительского элемента управления должен пристыковываться данный элемент. Перечисление DockStyle задает возможные значения этого свойства. Они могут быть такими: Top, Bottom, Right, Left, Fill и None. Значение Fill устанавливает размер данного элемента управления равным размеру родительского.

Свойство Anchor (якорь) прикрепляет грань данного элемента управления к грани родительского элемента управления. Это отличается от стыковки (docking) тем, что не устанавливает грань дочернего элемента управления точно на грань родительского, а просто выдерживает постоянное расстояние между ними. Например, если якорь правой грани элемента управления установлен на правую грань родительского элемента, и если родитель изменяет размер, то правая грань данного элемента сохраняет постоянную дистанцию от правой грани родителя — т.е. он изменяет размер вместе с родителем. Свойство Anchor принимает значения из перечисления AnchorStyle, а именно: Top, Bottom, Left, Right и None. Устанавливая эти значения, можно заставить элемент управления изменять свой размер динамически вместе с родителем. Таким образом, кнопки и текстовые поля не будут усечены или скрыты при изменении размеров формы пользователем.

Свойства Dock и Anchor применяются в сочетании с компоновками элементов управления Flow и Table (о которых мы поговорим позднее в этой главе) и позволя-

1062 Часть V. Презентации

ют создавать очень сложные пользовательские окна. Изменение размеров окна может оказаться достаточно непростой задачей для сложных форм с множеством элементов управления. Эти инструменты существенно облегчают задачу.

Внешний вид

Свойства, имеющие отношение к внешнему виду элемента управления — это

BackColor и ForeColor, которые принимают объект System.Drawing.Color в качестве значения. Свойство BackGroundImage принимает объект графического образа как значение. Класс System.Drawing.Image — абстрактный класс, служащий в качестве базового для классов Bitmap и Metafile. Свойство BackgroundImageLayout использует перечисление ImageLayout для определения способа отображения графического образа в элементе управления. Допустимые значения таковы: Center, Tile, Stretch,

Zoom или None.

Свойства Font и Text работают с надписями. Чтобы изменить Font, необходимо создать объект Font. При создании этого объекта указывается имя, стиль и размер шрифта.

Взаимодействие с пользователем

Взаимодействие с пользователем лучше всего описывается серией событий, которые генерирует элемент управления и на которые он реагирует. Некоторые из наиболее часто используемых событий: Click, DoubleClick, KeyDown, KeyPress,

Validating и Paint.

События, связанные с мышью — Click, DoubleClick, MouseDown, MouseUp,

MouseEnter, MouseLeave и MouseHover — описывают взаимодействие мыши и экранного элемента управления. Если вы обрабатываете оба события — Click и DoubleClick — то всякий раз, когда перехватывается событие DoubleClick, также возбуждается и событие Click. Это может привести к нежелательным последствиям при неправильной обработке. К тому же и Click, и DoubleClick принимают в качестве аргумента EventArgs, в то время как события MouseDown и MouseUp принимают MouseEventArgs. Структура MouseEventArgs содержит несколько частей полезной информации — например, о кнопке, на которой был выполнен щелчок, количестве щелчков на кнопке, количестве щелчков колесика мыши (при условии его наличия), текущих координатах X и Y указателя мыши. Если нужен доступ к любой подобной информации, то вместо событий Click или DoubleClick потребуется обрабатывать события MouseDown и MouseUp.

События клавиатуры работают подобным образом. Объем необходимой информации определяет выбор обрабатываемых событий. Для простейших случаев событие KeyPress принимает KeyPressEventArgs. Эта структура включает KeyChar, представляющий символ нажатой клавиши. Свойство Handled используется для определения того, было ли событие обработано. Установив значение Handled в true, можно добиться того, что событие не будет передано операционной системе для совершения стандартной обработки. Если необходима дополнительная информация о нажатой клавише, то больше подойдут события KeyDown или KeyUp. Оба принимают структуру KeyEventArgs. Свойства KeyEventArgs включают признак одновременного состояния клавиш <Ctrl>, <Alt> или <Shift>. Свойство KeyCode возвращает значение типа перечисления Keys, идентифицирующее нажатую клавишу. В отличие от свойства KeyPressEventArgs.KeyChar, свойство KeyCode сообщает о каждой клавише клавиатуры, а не только о буквенно-цифровых клавишах. Свойство KeyData возвращает значение типа Keys, а также устанавливает модификатор. Значение модификатора со-

Глава 31. Windows Forms 1063

провождает значение клавиши, объединяясь с ним двоичной логической операцией “ИЛИ”. Таким образом, можно получить информацию о том, была ли одновременно нажата клавиша <Shift> или <Ctrl>. Свойство KeyValue — целое значение из перечисления Keys. Свойство Modifiers содержит значение типа Keys, представляющее нажатые модифицирующие клавиши. Если было нажато более одной такой клавиши, их значения объединяются операцией “ИЛИ”. События клавиш поступают в следующем порядке:

1.KeyDown

2.KeyPress

3.KeyUp

События Validating, Validated, Enter, Leave, GotFocus и LostFocus имеют отношение к получению фокуса элементами управления (т.е. когда становятся активными) и утере его. Это случается, когда пользователь нажатием клавиши <Tab> переходит к данному элементу управления либо выбирает его мышью. Может показаться, что события Enter, Leave, GotFocus и LostFocus очень похожи в том, что они делают. События GotFocus и LostFocus относятся к низкоуровневым, и связаны с событиями Windows WM_SETFOCUS и WM_KILLFOCUS. Обычно когда возможно, лучше использовать события Enter и Leave. События Validating и Validated возбуждаются при проверке данных в элементе управления. Эти события принимают аргумент CancelEventArgs. С его помощью можно отменить последующие события, установив свойство Cancel в true. Если вы разрабатываете собственный проверочный код, и проверка завершается неудачно, то в этом случае можно установить Cancel в true — тогда элемент управления не утратит фокус. Validating происходит во время проверки, а Validated — после нее. Порядок возникновения событий следующий:

1.Enter

2.GotFocus

3.Leave

4.Validating

5.Validated

6.LostFocus

Понимание последовательности этих событий важно, чтобы избежать рекурсивных ситуаций. Например, попытка установить фокус элемента управления внутри обработчика события LostFocus создает ситуацию взаимоблокировки в цикле событий, и приложение перестает реагировать на внешние воздействия.

Функциональность Windows

Пространство имен System.Windows.Forms — одно из немногих, полагающихся на функциональность операционной системы Windows. Класс Control — хороший тому пример. Если выполнить дизассемблирование System.Windows.Forms.dll, то можно увидеть список ссылок на класс UnsafeNativeMethods. Среда .NET Framework использует этот класс как оболочку для всех стандартных вызовов Win32 API. Благодаря возможности взаимодействия с Win32 API, внешний вид и поведение стандартного приложения Windows можно обеспечить средствами пространства имен System. Windows.Forms.

Функциональность, которая поддерживает взаимодействие с Windows, включает свойства Handle и IsHandleCreated. Свойство Handle возвращает IntPtr, содержащий HWND (дескриптор окна) элемента управления. Дескриптор окна — это HWND, уни-

Источник

Первое приложение с .NET CLI

Последнее обновление: 11.11.2022

Для создания графических интерфейсов с помощью платформы .NET применяются разные технологии — Window Forms, WPF, UWP.
Однако наиболее простой и удобной платформой до сих пор остается Window Forms или сокращенно WinForms. Данное руководство ставит своей целью дать понимание принципов создания графических интерфейсов с помощью технологии WinForms
и работы основных элементов управления.

Создадим первое приложение на C# и Windows Forms. Что нам для этого потребуется? Прежде всего необходим текстовый редактор для написания кода программы.
Можно взять любой понравившийся текстовый редактор, например, Visual Studio Code

Также для компиляции и запуска программы нам потребуется .NET SDK. Для его установки перейдем на официальный сайт по ссылке
.NET SDK

После установки .NET SDK для первого проекта определим какую-нибудь папку. Например, в моем случае это будет папка C:dotnetwinformshelloapp.
Откроем терминал/командную строку и перейдем к созданной папке проекта с помощью команды cd

cd C:dotnetwinformshelloapp

В данном случае мы для создания и запуска проекта мы будем использовать встроенную инфраструктуру .NET CLI, которая устанавливается вместе с .NET SDK.

Для создания проекта в .NET CLI применяется команда dotnet new, после которой указывается тип проWindows Formsекта. Для создания проекта
Windows Forms применяется шаблон — winforms. Поэтому введем в терминале команду

После выполнения этой команды у нас будет создан следующий проект:

Структура проекта Windows Forms

Рассмотрим базовую структуру простейшего стандартного проекта Windows Forms:

helloapp.csproj: стандартный файл проекта C#, который соответствует назанию проекта (по умолчанию названию каталога) и описывает все его настройки.
helloapp.csproj.user: дополнительный файл проекта C#, который хранит специфичные для текущего пользователя настройки.
Form1.cs: содержит класс формы, которая по умолчанию запускается при старте приложения
Form1.Designer.cs: он содержит определение компонентов формы, добавленных
на форму в графическом дизайнере (графический дизайнер Windows Forms на данный момент официально доступен только в Visual Studio)
Program.cs: определяет класс Program, который запускается при старте приложения и запускает форму Form1

Например, посмотрим на содержимое файла helloapp.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net7.0-windows</TargetFramework>
    <Nullable>enable</Nullable>
    <UseWindowsForms>true</UseWindowsForms>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

</Project>

Для компиляции приложения Windows Forms указаны следующие настройки:

OutputType: определяет выходной тип проекта. Должен иметь значение WinExe — то есть выполняемое приложение с
расширением exe под Windows
TargetFramework: определяет применяемую для компиляции версию фреймворка .NET. Поскольку при создании проекта
была выбрана версия .NET 7, а сам проект зависит от компонентов Windows, то здесь должно быть значение net7.0-windows
Nullable: подключает в проект функционалность ссылочных nullable-типов
UseWindowsForms: указывает, будет ли проект использовать Windows Forms (для этого устанавливается значение true)
ImplicitUsings: подключает в проект функциональность неявно подключаемых глобальных пространств имен

Запуск проекта

Проект по умолчанию не представляет какой-то грандиозной функциональности, тем не менее этот проект мы уже можем запустить. Итак, запустим проект. Для этого выполним команду

При запуске запускается графическая форма, код которой определяет класс Form1:

Запуск приложения

Файл Program.cs определяет точку входа в приложение:

namespace helloapp;

static class Program
{
    [STAThread]
    static void Main()
    {
        ApplicationConfiguration.Initialize();
        Application.Run(new Form1());
    }    
}

Метод Main снабжен атрибутом [STAThread]. Этот атрибут, грубого говоря,
необходим для корректной работы компонентов Windows. В самом методе сначала вызывается метод

ApplicationConfiguration.Initialize()

который устанавливает некоторую базовую конфигурацию приложения

Затем вызывается метод

Application.Run(new Form1());

в который передается объект отображаемой по умолчанию на экране формы.

То есть, когда мы запустим приложение, сработает метод Main, в котором будет вызван метод Application.Run(new Form1()),
благодаря чему мы увидим форму Form1 на экране.

Определение формы

Теперь посмотрим на определение формы и немного изменим его. Для этого откроем файл Form1.cs в текстовом редакторе. По умолчанию он выглядит следующим образом:

namespace helloapp;

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
    }
}

Класс формы — Form1 представляет графическую форму — фактически то окно, которое мы увидим на экране при запуске проекта.

Этот класс определяется как частичный (с модификатором partial) и наследуется от встроенного класса Form,
который содержит базовую функциональность форм.

В самом классе Form1 определен по умолчанию только конструктор, где вызывается метод InitializeComponent(), который выполняет инициализацию компонентов формы из файла дизайнера
Form1.Designer.cs. По сути именно код этого файла передается выше через вызов InitializeComponent()

Теперь изменим его код следующим образом:

namespace helloapp;

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
        // определяем кнопку
        Button button = new Button();
        // текст кнопки
        button.Text ="Click";
        // положение кнопки
        button.Location = new Point(50, 50);
        // размер кнопки
        button.Size = new Size { Width = 80, Height = 30 };
        // обработчик нажатия кнопки
        button.Click += (o, e) => MessageBox.Show("Hello METANIT.COM!");
        // добавление кнопки на форму
        this.Controls.Add(button);
    }
}

В данном случае на форму добавляется кнопка, и у нее настраиваются различные свойства, как текст, положение на форме, размер, а также обработчик нажатия.
Заново запустим проект, и нам отобразится та же форма, которая теперь будет содержать кнопку. И по нажатию на кнопку появится маленькое окно с сообщением.

Источник

Файл:DotNet3.0.svg

Данный API — часть .NET Framework 3.0

Windows Forms — интерфейс программирования приложений (API), отвечающий за графический интерфейс пользователя и являющийся частью Microsoft .NET Framework. Данный интерфейс упрощает доступ к элементам интерфейса Microsoft Windows за счет создания обёртки для существующего Win32 API в управляемом коде. Причём управляемый код — классы, реализующие API для Windows Forms, не зависят от языка разработки. То есть программист одинаково может использовать Windows Forms как при написании ПО на C#, С++, так и на VB.Net, J# и др.

С одной стороны, Windows Forms рассматривается как замена более старой и сложной библиотеке MFC, изначально написанной на языке C++. С другой стороны, WF не предлагает парадигму, сравнимую с MVC. Для исправления этой ситуации и реализации данной функциональности в WF существуют сторонние библиотеки. Одной из наиболее используемых подобных библиотек является User Interface Process Application Block, выпущенная специальной группой Microsoft, занимающейся примерами и рекомендациями, для бесплатного скачивания. Эта библиотека также содержит исходный код и обучающие примеры для ускорения обучения.

Внутри .NET Framework, Windows Forms реализуется в рамках пространства имён System.Windows.Forms.

История и развитие[]

Как и Abstract Window Toolkit (AWT) (схожий API для языка Java), библиотека Windows Forms была разработана как часть .NET Framework для упрощения разработки компонентов графического интерфейса пользователя. Windows Forms построена на основе устаревающего Windows API и представляет собой, по сути, обертку низкоуровневых компонентов Windows.

Windows Forms предоставляет возможность разработки кроссплатформенного графического пользовательского интерфейса. Однако, Windows Forms фактически является лишь оберткой Windows API-компонентов, и ряд её методов осуществляют прямой доступ к Win32-функциям обратного вызова, которые недоступны на других платформах.

В .NET Framework версии 2.0 библиотека Windows Forms получила более богатый инструментарий разработки интерфейсов, toolstrip-элементы интерфейса в стиле Office 2003, поддержку многопоточности, расширенные возможности проектирования и привязки к данным, а также поддержку технологии ClickOnce для развертывания веб-приложений.

С выходом .NET Framework 3.0 Microsoft выпустила новый API для рисования пользовательских интерфейсов: Windows Presentation Foundation, который базировался на DirectX 11 и декларативном языке описания интерфейсов XAML. Однако, даже несмотря на все это, Windows Forms и WPF всё ещё предлагают схожую функциональность, и поэтому Windows Forms не был упразднен в пользу WPF, а продолжает использоваться как альтернативная технология построения интерфейсов наряду с WPF.

Отвечая на вопросы на конференции Build 2014, Майкрософт пояснила, что Windows Forms будет поддерживаться, ошибки будут исправляться, но новые функции добавляться не будут. Позже, улучшенная поддержка высокого разрешения для различных элементов интерфейса Windows Forms все же была анонсирована в релизе .NET Framework 4.5.

Архитектура[]

Приложение Windows Forms представляет собой событийно-ориентированное приложение, поддерживаемое Microsoft .NET Framework. В отличие от пакетных программ, большая часть времени тратится на ожидание от пользователя каких-либо действий, как, например, ввод текста в текстовое поле или клика мышкой по кнопке.

Альтернативные реализации[]

Mono — проект, финансируемый Novell (ранее — Ximian), одна из задач которого — создать стандарт Ecma, совместимый с набором инструментов .NET.

13 мая 2008 года API Mono System.Windows.Forms 2.0 была завершена (содержала 100 % классов, методов и т. д. из Microsoft System.Windows.Forms 2.0); также System.Windows.Forms 2.0 естественным образом работает и на Mac OS X.

См. также[]

Microsoft Visual Studio
ClickOnce
Abstract Window Toolkit
Visual Component Library, Borland VCL
Visual Test, инструмент автоматизации тестирования ГПИ

Примечания[]

Ссылки[]

MSDN: Building Windows Forms applications Шаблон:Ref-en
MSDN: Windows.Forms reference documentation Шаблон:Ref-en
MSDN: Windows Forms Technical Articles — Automating Windows Form with Visual Test Шаблон:Ref-en
Official community site Шаблон:Ref-en
Jeff Prosise: «Windows Forms: Современная модель программирования для создания GUI приложений»

Шаблон:Compu-soft-stub
Шаблон:Windows-stub
Шаблон:DotNET
Шаблон:Инструментарии виджетов

Источник

Architecture[edit]

Features[edit]

History and future[edit]

XAML backwards compatibility with Windows Forms[edit]

Alternative implementation[edit]

See also[edit]

References[edit]

External links[edit]

Architecture[edit]

Features[edit]

History and future[edit]

XAML backwards compatibility with Windows Forms[edit]

Alternative implementation[edit]

See also[edit]

References[edit]

External links[edit]

Первое приложение с .NET CLI

Структура проекта Windows Forms

Запуск проекта

Запуск приложения

Определение формы

История и развитие[]

Архитектура[]

Альтернативные реализации[]

См. также[]

Примечания[]

Ссылки[]