14. Windows Form

Le Windows Form, c’est-à-dire la fenêtre de l’application, est la pièce maîtresse de chaque application Windows. La version 4.6 du framework .NET introduit plusieurs nouvelles fonctionnalités dans la gestion des Windows Forms, que nous allons essayer d’analyser ci-dessous.

Créons une nouvelle application Windows (application Windows) avec le langage C#, comme indiqué dans la leçon précédente. Le projet inclut par défaut un formulaire Windows, contenu dans un fichier appelé Form1.cs.

Appuyez sur la touche F7 pour afficher le code source. Vous pouvez également cliquer avec le bouton droit sur le fichier « Form1.cs » affiché dans le Solution Explorer et sélectionner la commande View code (Afficher le code).

Le code est affiché :

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;

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

Tout d’abord, nous notons diverses clauses d’utilisation qui spécifient les espaces de nommage dans lesquels rechercher les classes qui seront utilisées.

L’ensemble de toutes les classes fournies par le Framework .NET appelle la bibliothèque de classes de base. C’est une vaste collection, et il est même impossible de mentionner toutes les classes qu’elle contient.

Ensuite est défini le namespace WindowsApplication1. Tous les Windows Forms créés avec Visual Studio, ainsi que les classes, les interfaces, les user control, etc., sont automatiquement insérés dans un espace de noms qui, par défaut, porte le même nom que le projet.

Ce paramètre peut être modifié en cliquant avec le bouton droit sur le nom du projet dans l’Explorateur de solutions et en sélectionnant la commande Propriétés.

Par défaut, VB.NET n’inclut pas les classes créées dans les espaces de noms par défaut.

Le code souligne que même un Windows Form est une classe qui hérite de la classe « Form ».

Regardons le mot-clé partial qui nous permet de définir des classes « partielles ».

En règle générale, chaque classe réside dans un fichier séparé, mais en utilisant des partiels, il est possible de créer des classes définies sur plusieurs fichiers. A partir de chaque fichier partiel, il est possible d’accéder aux variables, aux méthodes, aux propriétés de tous les autres fichiers partiels liés à la même classe, comme si la déclaration entière de la classe était contenue dans un seul fichier.

Ce nouveau concept favorise une plus grande netteté et lisibilité du code du Windows Form : le code de conception, qui définit les propriétés de la fenêtre et des contrôles qui y sont insérés, était précédemment sauvegardé dans le même fichier du formulaire, dans la région region Windows Form Designer generated code (Code généré par le Windows Forms Project), alors qu’il est maintenant stocké dans un fichier de support géré en interne par l’environnement de développement et appelé Form1.Designer.cs (au lieu de Form1 il y a le nom du formulaire).

Nous verrons que ce concept est très similaire à celui du code derrière dans les applications Web.

Le seul indice de l’existence de ce fichier est la méthode InitializeComponent() invoquée dans le constructeur du formulaire : comme dans les versions précédentes, il a pour tâche d’initialiser tous les objets contenus dans le formulaire.

Pour afficher le contenu du fichier Form1.Designer.cs, appuyez sur le bouton + à côté du nom du formulaire dans l’Explorateur de solutions.

Dans VB.NET, cependant, le fichier Designer par défaut est masqué. Pour l’afficher, vous devez cliquer sur le bouton Afficher tous les fichiers dans l’Explorateur de solutions. De plus, dans VB, le Windows Form n’est pas déclaré « Partiel » (même si, en réalité, il s’agit également d’une classe partielle).

Les classes partielles et leur utilisation dans Windows Forms peuvent sembler des nouveautés mineures qui, cependant, sont appréciées lors de la création d’une fenêtre avec un grand nombre de contrôles.

Dans les versions précédentes, le fichier de définition de Windows Forms reproduit une grande quantité de code maintenu par l’environnement de développement (que l’utilisateur n’aurait donc pas dû modifier, comme l’indiquent clairement les commentaires), au détriment de la lisibilité.

Visual Studio 2017 permet un placement des contrôles sur le Windows Form beaucoup plus facile que par le passé : la grille qui a couvert le formulaire dans la phase de conception a disparu, parce que maintenant les contrôles semblent « magnétisés » par les bords de fenêtre et d’autres objets ; de plus, pendant les opérations de traînage, des lignes directrices sont affichées pour permettre un positionnement plus précis des éléments dans la fenêtre.