Discussion :

[Pierre Fauconnier]

Salut Patrice,

En fait, tu as raison. Le formulaire peut se décharger lui-même. J'en étais resté à la considération théorique que ce n'était pas possible, mais ça l'est. Mea culpa

D'ailleurs, l'erreur 424 précise bien "objet requis"... Cela voudrait dire que UserForm1 a été probablement été renommé et qu'il faut donc modifier la ligne.

Quoi qu'il en soit, le déchargement/rechargement du formulaire, qu'ils soient effectués dans le code du formulaire ou en dehors, me semble plus rationnel que les lignes de vidange de chaque contrôle, surtout que, comme je l'ai dit, il n'est pas dit que les textbox étaient vides au premier chargement (valeur par défaut entre Load et Show, ou sur lInitalize). Vider les contrôles n'amène pas à passer par Initialize, alors que le déchargement/rechargement oblige à passer par Initialize si présent.

Cela étant, ça ne change rien à l'architecture à mettre en place, selon moi. Si le formulaire se décharge (ou est déchargé), on ne sait plus en exploiter les données, par définition. Ce qui implique que tout le traitement doit être fait à l'intérieur du formulaire, avant le déchargement pour en exploiter les données, et dans le Initialize du formulaire pour définir certaines valeurs par défaut lors du chargement, puisque ces traitements ne peuvent plus être effectués par la procédure appelante. Tout mettre dans le formulaire, en ce compris donc son initialisation et le traitement des données après saisie, de surcroît avec le code de traitement dans le bouton CommandButton1 pour ce qui est de l'exemple, amène à un couplage fort entre le formulaire et les données, réservant le formulaire à un usage particulier, alors qu'une bonne architecture demande que les couches de présentation et de gestion des données soient séparées (architecture "trois tiers"). Respecter cette architecture amène selon moi plus de souplesse dans l'utilisation du formulaire( modification des valeurs au chargement par exemple, et traitement des données après saisie et masquage du formulaire (Me.Hide).

Partant de là et étant farouche partisan d'une systématisation de la façon de programmer, j'ai étendu cette manière à tout formulaire, quel que soit son utilisation finale. C'est pour cela que le code que j'ai proposé illustre une façon de travailler avec les tables de données et les formulaires, permettant de détacher le formulaire de la structure de la feuille de calcul et permettant également de gérer d'autres feuilles de calcul (de structure similaire) au travers d'un seul et même formulaire

[Invité]

en fait je pense que c'est cela que le demandeur souhaite (spéculation? laisson le répondre!)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Private Sub CommandButton2_Click()
Dim modif As Integer
If Not ComboBox1.Value = "" Then
Sheets("source").Select
modif = ComboBox1.ListIndex + 1
Cells(modif, 10) = TextBox1.Value
Cells(modif, 1) = ComboBox1.Value
Cells(modif, 12) = TextBox2.Value
Cells(modif, 13) = TextBox3.Value
Cells(modif, 14) = TextBox4.Value
Cells(modif, 15) = TextBox5.Value
Cells(modif, 16) = TextBox6.Value
MsgBox ("Modification effectuer")
Else
MsgBox ("Veuillez sélectionné le Nom/Prénom de la personne a modifier")
Exit Sub
End If
ComboBox1.ListIndex = -1
TextBox1.Value = ""
TextBox2.Value = ""
TextBox3.Value = ""
TextBox4.Value = ""
TextBox5.Value = ""
TextBox6.Value = ""
'Unload UserForm1
'UserForm1.Show 0
End Sub

Tu penses autrement? Ok, je suis sincèrement ouvert. Montre-moi, arguments à l'appui, que ta technique est meilleure que la mienne... J'ai bien dit arguments à l'appui... Si c'est pour dire "code farfelu et ésotérique", "Décharge puis recharger un formulaire c'est absurde", ne te fatigue pas, tu seras pour moi, de manière définitive parce que tu commences à me fatiguer grave, un troll de chez troll.

il n'y a pas d'argumentaire à la bêtise!

Mais qui a dit que les textbox devaient être réinitialisés avec un chaine vide? A priori, les contrôles doivent être réinitialisés pour afficher les valeurs qu'ils avaient lorsque l'on a chargé le formulaire pour la première fois. Et quelle est la meilleure technique pour réaliser cela, d'une manière générique et sous l'angle de la systématisation du code? Hé bien, à part décharger et recharger le formulaire, je ne vois pas. On aurait pû mette le code dans le Initialize du userform puis rappeler cette procédure, mais pour moi, selon mes standards, ce n'est pas à cela que sert le Initialize d'un formulaire. Si tu n'es pas d'accord, ok, mais argumente autrement qu'à coup de "c'est stupide", parce que cela, ça fait partie des "arguments" les plus grotesques que je connaisse, de ceux que l'on brandit lorsque l'on est à court d'arguments techniques mais que l'on veut quand même avoir raison.

Code Mais qui a dit que les textbox devaient être réinitialisés avec un chaine vide :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
'Unload UserForm1
'UserForm1.Show 0
End Sub

[Pierre Fauconnier]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
unload userform1
userform1.show

n'implique absolument pas que les textbox doivent être vides. Si ton userform a le code suivant, par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
sub initialize()
textbox1.value=format(date,"dd/mm/yy")
end sub

Ton code textbox1.value="" n'y mettra pas la date du jour alors que le déchargement/rechargement le fera.


Pour la cohérence de mon code farfelu, forcément que si tu as x contrôles, en l'absence de la mise en place d'une boucle, tu auras x lignes qui transfèrent les données du userform dans la table de données. Ca me paraît normal et je ne vois rien de farfelu ni d'incohérent là-dedans. Il faudrait normalement programmer différemment avec une boucle qui balaie une table de mappage, mais chaque chose en son temps. Ca ne peut se réaliser que dans une architecture propre et certainement pas avec plein de code dans un commandbutton1_click. C'est une chose d'avoir x lignes de transfert, c'en est une autre d'avoir x lignes de nettoyage alors que deux suffisent et qu'en plus, elles réalisent le travail correctement, à savoir réinitialiser les contrôles comme ils doivent l'être et que rien ne dit, avec le code parcellaire qui a été donné, qu'il n'y a pas un Initialize à faire jouer.


Pour ce qui est du mépris dont tu parles, prends-le comme tu veux. Je maintiens que ce n'est pas codé proprement que de coder la vérification, le transfert en table et le nettoyage dans une procédure événementielle. Pourquoi? Parce que tu ne sais pas tester correctement les portions de code qui ont des responsabilités différentes. Tu ne sais tester ton nettoyage qu'en réalisant ton transfert. Une bonne pratique en programmation est d'écrire des procs/fonctions qui ont une et une seule responsabilité. Ici, le code du bouton en a trois: Vérifcation, transfert, nettoyage. Ce n'est pas coder proprement que de coder ainsi. Et que tu prennes cela pour du mépris ou pour ce que tu veux, je m'en fous, je maintiens que, pour moi, ce n'est pas coder proprement. Pour moi, si on veut nettoyer dans le userform avec du code propre et une architecture correcte, il faudrait a minima ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
sub commandbutton1_click()
  if DatasAreOk then
    transferInTable
    ClearControls
  else
    msgbox...
  end if
end sub
 
function DataAreOk() as boolean
  ...
  ...
end function
 
sub TransferInTable()
  ...
  ...
end sub
 
sub ClearControls()
  ...
  ...
end sub

Comme ton seul "argument" est de dire que c'est farfelu, je m'en fous royalement. Je sais que programmer comme je le fais est mieux que de programmer tout à l'arrache dans une proc événementielle, et ton avis m'importe peu. Les lecteurs jugeront nos arguments respectifs. C'est bien plus pour eux que pour toi que je détaille autant mes réponses.

Pour ce qui est de tes "arguments", n'ayant rien vu d'autre que de l'insulte, je ne saurais pas juger de leur pertinence.


Je terminerai en disant que j'agis ici sous mes vrais nom et prénom, et que je ne me cache pas lâchement derrière un pseudo pour parler de code farfelu et autres sans aucune justification technique. Ce que je dis ici, je l'assume au grand jour, et je préfère mille fois une approche systématique du code et ma manière "farfelue" de coder et d'approcher la programmation que la tienne

Si maintenant on pouvait laisser la parole au demandeur initial et laisser les lecteurs apprécier nos approches respectives, ce serait chouette. Je ne te convaincrai pas, et bien sûr, tu ne me convaincras pas non plus, surtout sans arguments et en utilisant l'insulte.

[Invité]

tu as vraisemblablement un problème d'égo et je ne vois pas comment ça aiderait le demandeur de discuter avec toi!

pour le pseudo ça me paraissait légale sur développez.com, pour me cacher derrière encor faut et tu sais ce que je veux dire!

avant c'était mon nom qui apparaissais! je recevais des mail en privé qui trouvais mon pseudo rigolo ou qui m'insultaient pour mes fautes d’orthographe! quand j'ai ouvert un compte au nom de dysorthographie c'est toi qui ma demander de faire un choix!

j'ai distribué un -1 à pierre sur tous les postes c'est drôle ils ont disparue!



je ne critique pas sens vérifier! pourquoi le formulaire ne contient pas la totalité du code? ha oui c'est pas propre!



au revoir ok corral!

[Chernobyl123]

Merci Pierre Fauconnier et dysorthographie pour votre aide !
malgré votre mésentente sur le code ,vos arguments sont très utiles et sont source de savoir,ça ma appris beaucoup de choses !
en faite il a fallu juste que je modifie ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
'Unload UserForm1
'UserForm1.Show 0
End Sub

Grand merci !