C# Sauvegarder les données de formulaire dans un fichier: Une analyse approfondie avec Tim Corey
C Nam : Enregistrer les Données du Formulaire dans un Fichier : Une Analyse Approfondie avec Tim Corey (Leçon 23)
Enregistrer de manière fiable les données saisies par l'utilisateur est l'une des responsabilités les plus importantes d'une application de bureau. Vous pouvez créer une application Windows Form dans Visual Studio sur Windows pour implémenter la fonctionnalité d'enregistrement de fichiers. Dans la leçon 23 de la série "C# App Start to Finish", Tim Corey explique exactement comment une application WinForms prend les données saisies sur un formulaire, les valide, les met à jour dans des modèles en mémoire, et les persiste finalement soit dans une base de données, soit dans un fichier texte.
Dans cet article, nous allons examiner de plus près l'enregistrement des données de formulaire C# dans un fichier, strictement en expliquant la vidéo de Tim étape par étape. Nous couvrirons comment démarrer un nouveau projet dans Visual Studio, concevoir le Windows Form avec des contrôles comme des zones de texte, et utiliser des composants tels que SaveFileDialog pour permettre aux utilisateurs de parcourir et de sélectionner un chemin et un type de fichier (par exemple, csv, jpeg) à l'aide de filtres. L'objectif est de comprendre comment et pourquoi Tim relie les choses ensemble dans cette leçon afin que les lecteurs puissent suivre avec clarté.
Revue du Visualiseur de Tournoi et Objectif du Jour
À 0:01, Tim souhaite la bienvenue aux spectateurs à la leçon 23 et explique que l'objectif d'aujourd'hui est de terminer le formulaire du visualiseur de tournoi. Il nous rappelle que la plupart de l'interface utilisateur est déjà configurée :
-
le menu déroulant des tours
-
la liste des matchs
-
les étiquettes de nom d'équipe
- les zones de texte pour les scores
Vous pouvez définir des propriétés comme la propriété Multiline pour les zones de texte des scores afin de permettre aux utilisateurs de saisir plus de données si nécessaire.
Tim explique qu'aujourd'hui il va connecter deux éléments restants :
-
La case à cocher "Non joué seulement"
- Le bouton Score, y compris l'enregistrement des résultats dans le stockage
Après avoir ajouté le bouton Score, vous pouvez faire un clic droit sur le formulaire et sélectionner 'Voir le code' dans Visual Studio pour connecter les gestionnaires d'événements.
Il déclare clairement qu'une fois que le bouton de score fonctionne, l'application enregistrera les données soit dans une base de données, soit dans un fichier texte, c'est là que notre sujet principal entre en jeu.
Filtrage des confrontations avec la case à cocher " Non jouées uniquement "
À 1:02, Tim ouvre la fenêtre Propriétés pour la case à cocher et double-clique sur l'événement CheckedChanged. Il explique que chaque fois que la case à cocher change d'état, la liste des matchs doit être rechargée.
Tim souligne que la logique existe déjà dans une méthode appelée LoadMatchups, donc au lieu de réinventer quoi que ce soit, il appelle simplement cette méthode à nouveau depuis l'événement de la case à cocher.
Vers 1:57, Tim modifie LoadMatchups pour inclure une logique conditionnelle. Il passe en revue l'ajout d'une instruction if qui vérifie si le gagnant d'un match est nul. Si c'est le cas, le match n'a pas encore été joué.
Puis à 3:10, Tim introduit la condition OR qui fait fonctionner la case à cocher. Il explique la logique en termes simples :
-
Si une confrontation n'a pas de gagnant, affichez-la
- OU, si la case à cocher n'est pas cochée, montrez tout
Tim parcourt minutieusement les tables de vérité verbalement, expliquant pourquoi :
-
coché + terminé = caché
- non coché = toujours visible
Il suggère même de dessiner cette logique sur papier lorsque les conditions deviennent complexes.
Connecter le bouton Score et lire les valeurs du formulaire
À 5:45, Tim double-clique sur l'événement du bouton de score. Il explique qu'en cliquant sur ce bouton, vous devez :
-
Lire les valeurs du formulaire (l'entrée est généralement traitée sous forme de chaîne, qui sera traitée et la sortie enregistrée dans un fichier)
-
Mettre à jour l'objet de confrontation sous-jacent (cette logique est encapsulée dans une classe)
- Décidez d'un gagnant
À 6:26, Tim récupère la confrontation sélectionnée à partir de la liste et explique que cet objet détermine quelles équipes appartiennent à " Équipe Un " et " Équipe Deux ".
Il montre ensuite comment boucler à travers les entrées des matchs et explique qu'au lieu de définir des champs de texte, l'objectif est désormais de prendre les valeurs de texte et de les enregistrer dans les propriétés de score. Le code suivant montre comment écrire les données dans un fichier.
À 7:45, Tim convertit l'entrée de texte en doublons et s'arrête immédiatement pour avertir des entrées utilisateur invalides. Il insiste sur le fait que les données saisies par l'utilisateur doivent toujours être validées.
Validation des saisies avec TryParse
À 8:39, Tim remanie l'analyse du score en utilisant une approche plus sûre avec double.TryParse. Il explique que cela empêche l'application de planter si l'utilisateur tape quelque chose d'invalide comme du texte au lieu d'un nombre.
À 10:20, Tim enveloppe la logique de l'analyse dans une instruction if :
-
Si l'analyse réussit, continuez
- Si elle échoue, affichez une boîte de message et revenez
Il explique qu'utiliser return quitte immédiatement la méthode, empêchant ainsi les mauvaises données de se propager plus loin dans le système.
Ce modèle est répété pour les scores de l'Equipe Un et l'Equipe Deux.
Déterminer le gagnant et gérer les cas particuliers
À 14:25, Tim compare les deux scores pour déterminer un gagnant. Si le score de l'Équipe Un est plus élevé, cette équipe est désignée comme le gagnant de la confrontation.
À 16:41, Tim discute des règles de notation et explique que son application suppose que le score le plus élevé gagne. Il note que si quelqu'un voulait supporter que le score le plus bas gagne (comme au golf), cette logique pourrait être inversée ou rendue configurable.
À 17:42, Tim gère les égalités de façon explicite. Au lieu de choisir silencieusement un gagnant, il montre un message indiquant que les égalités ne sont pas prises en charge et évite intentionnellement de sauvegarder un gagnant.
Correction des bugs et gestion de la visibilité de l'interface utilisateur
À 20:14, Tim rencontre un bug lorsqu'il ne reste plus de match non joué. .Il explique pourquoi appeler .First() sur une liste vide provoque une exception et le corrige en vérifiant d'abord le nombre dans la liste.
À partir de 23:05, Tim explique sa philosophie de débogage. Il recommande fortement d'écrire les bugs sur papier pour éviter les distractions numériques et rester concentré.
À 24:49, Tim introduit une nouvelle méthode appelée DisplayMatchupInfo. Il explique que les éléments de l'interface utilisateur comme les étiquettes, les boîtes de texte et le bouton Score ne devraient être visibles que lorsqu'une confrontation est sélectionnée.
À 28:28, tous les contrôles associés basculent automatiquement la visibilité en fonction de la présence d'une sélection valide.
Rafraîchir la liste après que le score soit comptabilisé
À 29:57, Tim explique qu'après avoir cliqué sur Score, la liste des confrontations doit se rafraîchir immédiatement. Il appelle simplement LoadMatchups() à nouveau à la fin de la logique du bouton de score.
Il démontre qu'une fois qu'une confrontation est notée, elle disparaît de la liste lorsque " Non jouées uniquement " est cochée.
Enregistrement des données de confrontation dans la base de données
À 31:16, Tim passe à l'enregistrement des données. Il introduit une nouvelle méthode dans l'interface d'accès aux données appelée UpdateMatchup.
À 33:14, Tim explique pourquoi cette méthode retourne void. Il souligne que les objets sont passés par référence, donc les mettre à jour met à jour les données originales.
Il crée ensuite des procédures stockées :
-
Une pour mettre à jour le gagnant de la confrontation
- Une pour mettre à jour les entrées et les scores de la confrontation
Tim avertit fortement à 38:08 sur l'absence de clauses WHERE dans les mises à jour SQL, expliquant comment une seule erreur peut écraser tous les enregistrements.
À 49:58, il appelle GlobalConfig.Connection.UpdateMatchup(m) depuis le formulaire, sauvegardant officiellement les données dans le stockage persistant.
Mise à jour et enregistrement des confrontations dans un fichier texte
À 52:32, Tim passe au connecteur de fichier texte. Il explique que la plupart du code existe déjà et peut être adapté.
Après avoir enregistré dans un fichier texte, il est important de noter que toutes les opérations de fichier en C nécessitent d'inclure la bibliothèque
En utilisant le composant SaveFileDialog dans .NET, les utilisateurs peuvent parcourir le système de fichiers et sélectionner les fichiers à enregistrer. La boîte de dialogue retourne le chemin et le nom de fichier sélectionnés par l'utilisateur, et vous pouvez utiliser la propriété DialogResult pour obtenir le nom du fichier. Après avoir sélectionné un fichier, vous devez écrire le code pour réellement écrire les fichiers sur le disque. La méthode OpenFile de SaveFileDialog vous donne un objet Stream sur lequel vous pouvez écrire, vous permettant ainsi de sauvegarder la sortie dans le fichier sélectionné.
À 53:49, Tim partage une philosophie clé :
" Il est plus important de faire fonctionner votre application que d'écrire un code incroyable. "
Il copie la logique de sauvegarde existante et la modifie en UpdateMatchupToFile. Au lieu d'ajouter de nouveaux enregistrements, il supprime l'ancien match et le remplace par le nouveau.
À 59:27, Tim répète ce même modèle pour les entrées des matchs, en veillant à ce que les scores et les affectations d'équipes soient correctement mis à jour dans le fichier.
À 1:02:44, Tim démontre le redémarrage de l'application et confirme que les données persistent, prouvant que les données du formulaire ont été correctement sauvegardées dans le fichier.
Pour gérer les fichiers CSV dans les applications WinForms .NET, vous pouvez importer des fichiers CSV en utilisant la méthode LoadTextFile de la classe SheetView, exporter des fichiers CSV en utilisant la méthode SaveTextFile, et convertir des fichiers CSV au format Excel XLSX en utilisant les méthodes SaveExcel de la classe FpSpread. Le composant Spread.NET offre une fonctionnalité robuste de gestion des fichiers CSV, ce qui facilite la gestion des fichiers CSV au sein de votre application. Pour un projet d'exemple et un guide étape par étape, consultez ce blog ou téléchargez l'application d'exemple démontrant cette fonctionnalité.
Réflexions finales de Tim Corey
Dans les dernières minutes, Tim explique que l'enregistrement des données n'est qu'une partie du processus. Une fois un match terminé, l'équipe gagnante doit passer au tour suivant, ce qu'il commence à préparer ensuite.
Il termine la leçon en mettant l'accent sur une validation minutieuse, des progrès incrémentaux, et en se concentrant d'abord sur un logiciel fonctionnel, avec une refactorisation plus tard. Nous espérons que cet article vous sera utile et que la solution fournie vous aidera à implémenter l'enregistrement de données de formulaire dans un fichier dans vos propres projets.
Résumé
Dans cette leçon, Tim Corey montre—étape par étape—comment les données de formulaire WinForms C# passent de l'interface utilisateur → validation → mises à jour du modèle → stockage de fichiers. L'article fournit un exemple et un flux de travail modèle pour sauvegarder les données de formulaire dans un fichier. Après avoir écrit le code, vous pouvez exécuter le projet en appuyant sur F5 dans Visual Studio pour tester la fonctionnalité. En suivant son approche, les développeurs peuvent clairement voir comment les applications réelles sauvegardent en toute sécurité les entrées utilisateur sans perdre de données ou planter.
Cette leçon est un plan pratique pour sauvegarder les données de formulaire de la bonne manière, exactement comme Tim l'enseigne.
