Poo et utilisation de quelques boites de dialogue (save et open) et des usercontrols

Soyez le premier à donner votre avis sur cette source.

Vue 6 555 fois - Téléchargée 1 081 fois

Description

le "logiciel" n'est pas utile en lui méme mais il permet de comprendre plusieurs notions sur :
  • la programmation orienté objet comme :

--l'encapsulation des attributs de la classe
--la création de constructeurs
--l'instanciation d'un objet
--l'utilisation des property de classe
  • Utilisation de quelques controls utilisateurs (usercontrols) comme:

--les listbox
--les combobox
et les classiques boutton et textbox
  • Utilisation des boites de dialogues comme:

--savefiledialog
--openfiledialog

et illustre la creation de nouveau fichiers (ici c'est des fichiers texte) ainsi que l'ecriture ou la modification dans c'est fichiers ou la lecture on utilisant respéctivement les fameux StreamWriter et StreamReader ainsi que la création des Fénetres MDI

et la gestion des erreurs est faites avec le Try ... Catch
....

Source / Exemple :


'go to zip

Conclusion :


desole pour les commentaires je les ajouterai aperes la fin des examens

Remarque Importante : cette source ne sert pas a creer une application de gestion de quoique se soit mais pour les creer il faut utilisé les bases de données et il y a plusieurs source traitant du sujet

c'est juste un exemple

merci Mayzz pour la remarque

Codes Sources

A voir également

Ajouter un commentaire Commentaires
Messages postés
127
Date d'inscription
lundi 11 octobre 2004
Statut
Membre
Dernière intervention
18 mai 2016

1 --> je vois pas le probleme entre laisser les noms par defaut aux "controls" ou les changer

Si tu n'as qu'un seul type de contrôle par formulaire, ça passe à la rigueur.

Le jour où tu te retrouves avec 50 textbox ou 30 combobox ou 10 boutons ou etc..., et que tu devras revenir sur ton code pour corriger 1 bug ou pour optimiser une fonctionnalité, tu remarqueras peut-être le temps que tu vas perdre à savoir qui est qui.

De plus, si tu adresses ta source aux débutants, comment-veux tu qu'ils assimilent le code s'ils ne savent pas de quoi il s'agit ?

Qu'est ce qui est le plus clair ?

Ceci ?
TextBox1
TextBox2
TextBox3
TextBox4
TextBox5
ComboBox1
ComboBox2
ComboBox3
Button1
Button2
Button3

ou celà ?

TextBox_Nom
TextBox_Prénom
TextBox_Adresse
TextBox_CP
TextBox_Ville
ComboBox_Niveau
ComboBox_ListeVerte
ComboBox_ListeRouge
Button_OK
Button_Appliquer
Button_Annuler

Nommer explicitement ses contrôles est une évidence.
Messages postés
13280
Date d'inscription
lundi 13 décembre 2004
Statut
Modérateur
Dernière intervention
3 février 2018
47
conseiller un débutant de ne pas nommer ses contrôles parce qu'il s'y retrouve mieux, c'est aussi l'empêcher de comprendre les sources "normalement" codées

qu'on hésite à renommer un bouton en "btnAction, Btn_Action, Cmd_Action", ok. mais plus généralement avoir 50 boutons et les laisser nommés par défaut ne peut que nuire à tout le monde (lecteur averti qui cherche lequel est où, lecteur débutant qui passe encore plus de temps à chercher tout en prenant aussi de mauvaises habitudes, et aussi l'auteur qui reste dans le 2e cas)

le framework et plus généralement dotnet (vb, c#, etc..) donc l'IDE par lui-même ont été fait de manière à accélérer le temps de RéALISATION de code
(reste à prendre le temps de comprendre les subtilités de quoi utiliser au lieu de quoi, même s'il y a toujours plusieurs manières de faire la même chose)

le temps gagné ne doit pas être re-perdu parce qu'on a pas ouvert son projet pendant 2 mois.
on lit par exemple "
sub cmdReadFile_Click(...)
dim reader as io.textreader = io.file.opentext(txtFile.text)"
, on sait tout de suite qu'on va récupérer le contenu d'un 'fichier' dont le 'chemin' est dans une 'zone de texte', ce par l'action 'click' d'un 'bouton'. on n'a pas besoin d'aller vérifier sur le formulaire où est le bouton command45 (nommer suffit ici à ne pas avoir besoin de connaître son emplacement), ni que c'est un chemin ou une chaine (on sait), ni que c'est une zone de texte, ni ou elle est, etc...

on doit pouvoir comprendre à la simple lecture sans même (pour les petits projets) avoir besoin de regarder l'interface

on peut comprendre éventuellement qu'un label NON utilisé par code (ex : label13.text = "machin") ne soit pas nommé, ce n'est qu'une étiquette graphique utilisée qu'en mode design, pour tout contrôle lié à du code il est nécessaire de se forcer à s'organiser (surtout comme le souligne nhervagault quand on est sujet à toucher à plusieurs langages)

on comprend bien sûr que çà ne se fasse pas en un claquement de doigts, mais refuser cet effort ne peut mener qu'à des confusions et, quand on souhaite partager ses sources, qu'à - au final - des échanges inutiles par nature
(cette intervention en haut de la liste évidemment :))
Messages postés
2813
Date d'inscription
mardi 15 avril 2003
Statut
Membre
Dernière intervention
2 juin 2020
38
Je passais par la, et je voulais juste dire que je ne suis pas spécialement d'accord sur les noms de contrôles, nous, nous somment habitués à "cmdNext", chk_send", txtPath", mais pour un débutant cela ne parle pas trop justement eux son habitués à développer avec des TextBox1, ComboBox2, etc...

Oui, ce n'est pas un exemple c'est sur, autant leur montrer que rennommer ses contrôles c'est organiser son travail, mais si l'exemple leurs parrait illisible, alors il ne sert plus à rien, d'ailleurs, dans les exemples MSDN les controles ne sont pas toujours renommés.
Messages postés
23
Date d'inscription
mardi 24 octobre 2006
Statut
Membre
Dernière intervention
23 février 2011

pour le point 5 j'y avait pensé c'est juste que j'avais oublié de l'appliquer je le ferait tres prochainement

merci ;)
Messages postés
6063
Date d'inscription
dimanche 13 avril 2003
Statut
Modérateur
Dernière intervention
15 juillet 2011
36
Mes remarques sont justes pour te faire progresser et avoir une programmation plus propre.

Pour le point 1 btnPrecendent est plus parlant que button1 et le programme devient plus maintenable.

De plus, par exemple le point 3. permet une performance plus intéressante (pas de casting implicite qui fait appele a la
reflexion)
Je sais que pour une petite application,c'est pas trop grave mais si tu veux montrer une maniere de programmer mieux vaut qu'elle soit la plus correcte possible ;-)

Pour le point 5.
# TextBox1.Text = prod.aRefProd
# TextBox2.Text = prod.aNomProd
# ComboBox1.Text = prod.aCategorie
# TextBox3.Text = prod.aPrixU
# TextBox4.Text = prod.aNomFournisseur

Est present plusieurs fois
--> une fonction
sub fill(prod as Produit)
TextBox1.Text = prod.aRefProd
TextBox2.Text = prod.aNomProd
ComboBox1.Text = prod.aCategorie
TextBox3.Text = prod.aPrixU
TextBox4.Text = prod.aNomFournisseur
end sub

Et Voila 15 lignes de code de gagnées
et si tu ajoutes un champ exemple TVA tu as que cette fonction à modifier.
à la place de 4 fonctions.

Point6 si un jour tu passes par exemple au c# tu auras moins de probleme en appliquant ces regles.
Afficher les 14 commentaires

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.