Share via


Structure de programme et flux d'exécution

Mise à jour : novembre 2007

Lorsque vous créez une application C#, vous avez le choix entre créer une application console ou une application Windows Forms. Les deux diffèrent non seulement par le type d'interface utilisateur, mais elles peuvent également différer dans leur flux d'exécution.

Applications Windows Forms

Dans une application Windows standard dotée d'une interface graphique utilisateur, la plupart des actions qui interviennent après le démarrage initial sont effectuées en réponse à des actions de l'utilisateur (déplacement de la souris, sélection d'une option de menu, saisie de texte, etc.). Ces actions déclenchent des événements et des méthodes spéciales dans votre application nommées gestionnaires d'événements. La majorité des actions effectuées par un programme Windows sont initialisées par un gestionnaire d'événements. Lorsque aucun événement n'est généré, le programme n'effectue aucune action.

Si vous êtes habitué aux langages de programmation procéduraux, tels que COBOL, BASIC ou FORTRAN, vous devez vous familiariser avec le modèle piloté par évènement. Dans la programmation pilotée par évènement, la différence réside essentiellement dans le fait que d'autres logiciels, y compris le système d'exploitation lui-même, appellent des méthodes de gestionnaire d'événements dans votre application. Vous ne pouvez pas connaître les méthodes qu'ils vont appeler. Vous pouvez choisir les événements à gérer dans votre application, mais vous ne pouvez pas connaître à l'avance l'ordre exact dans lequel ces événements vont survenir.

Dans une application Windows standard, les champs, les tableaux et les collections qui contiennent l'état de l'application sont placés dans la classe Form principale qui est nommée Form1 par défaut. Dans la portée de la classe, ces membres sont accessibles à partir de toutes les méthodes de gestionnaire d'événements qui sont implémentées dans la même classe Form. Lorsqu'un gestionnaire d'événements est appelé, il peut faire quelque chose pour modifier les données d'application, et lorsque la méthode retourne, l'application poursuit son état d'attente. Par exemple, un formulaire peut contenir un contrôle TextBox et un bouton Mettre à jour. Lorsque l'utilisateur clique sur le bouton, le gestionnaire d'événements de l'application peut obtenir le texte figurant dans le contrôle TextBox, puis l'ajouter à la liste des autres chaînes qui sont stockées dans la portée de la classe. Après avoir ajouté la chaîne, l'application retourne à l'état d'attente. D'autres gestionnaires d'événements peuvent effectuer d'autres types d'actions dans cette même liste de chaînes en réponse à l'entrée d'utilisateur.

Vos propres classes personnalisées peuvent envoyer et recevoir des événements à l'aide des mêmes mécanismes que ceux des Windows Forms. Pour plus d'informations, consultez Délégués (Guide de programmation C#).

Applications console

Dans beaucoup d'applications de console, le flux d'exécution se poursuit d'une instruction vers la suivante jusqu'à la fin du programme et de l'application. Ce n'est bien sûr pas toujours le cas, car une application console peut encore être pilotée par des événements de clavier et des événements système générés par des objets tels que les horloges et les connexions réseau. Les applications console simples se composent souvent d'une seule classe, celui qui contient la méthode Main. Toutefois, les applications plus complexes peuvent contenir n'importe quel nombre de classes.

Pour plus d'informations

La meilleure façon d'étudier la structure de programmes C# consiste à examiner l'exemple de code qui figure dans Exemples Visual C#, dans le Centre de développement Visual C# et sur d'autres sites Internet.

Voir aussi

Tâches

Comment : créer une nouvelle application Visual C# Express

Concepts

Initiation au langage C#

Ordre des événements dans les Windows Forms

Événements liés à la souris dans les Windows Forms