Discussion :

[Chernobyl123]

Bonjour ! debutant VBA ici,
J'ai le code ci-dessous :

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
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
Unload UserForm1
UserForm1.Show 0
End Sub

Le formulaire marche a perfection,les modifications sont effectue,mais apres ca fait une erreur d'execution 424 ?! quand j'appuie sur debodage ca met "unload userform1" en jaune.
quand je le supprime ca marche plus...comment fixer ça et pourquoi ça donne cette erreur ?
merci !

[Invité]

Il faut juste réinitialiser les contrôles !

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
ComboBox1.ListIndex =-1
TextBox1.Value=""
TextBox2.Value=""
TextBox3.Value=""
TextBox4.Value=""
TextBox5.Value=""
TextBox6.Value=""
'Unload UserForm1
'UserForm1.Show 0
End Sub

[Pierre Fauconnier]

Salut.

Il est inutile de reseter le formulaire par autant de lignes qui passent des chaines vides. Heureusement que tu n'as pas une centaine de contrôles dans ton userform.

Il suffit de décharger le formulaire par un unload. Encore faut-il le mettre au bon endroit. Tu peux facilement comprendre qu'un bouton du formulaire ne peut pas permettre de décharger ce dernier, puisqu'il doit être actif pour exécuter le code. Un formulaire ne saurait donc forcément pas se décharger lui-même. Il faut donc le décharger et le recharger ailleurs. C'est, encore une fois, un problème d'architecture.


La bonne séquence de vie d'un formulaire est d'être chargé par une procédure appelante, puis d'être masqué par le bouton Valider ou Annuler, et éventuellement rechargé. Dès lors, ce n'est pas au formulaire de transférer les données dans ta table. Sa seule responsabilité est de mettre à disposition de l'utilisateur une possibilité de saisie de donnée, de vérifier la cohérence de la saisie, puis de permettre à la procédure qui l'a chargé de transférer les données. Cette procédure pourra alors décharger puis recharger le formulaire, ce qui le réinitialisera. Dans une architecture de ce type, c'est au formulaire qu'incombe la responsabilité de vérifier la cohérence des saisies, et c'est à la procédure appelante de le "nettoyer" pour la saisie suivante.

Je te propose le code suivant, qui pourrait être mieux architecturé mais qui sera exemplatif de ce vers quoi il faut aller.


Voici le code du formulaire, qui vient compléter/corriger ce qui existe déjà. Il y a deux boutons, un qui valide la saisie et un qui stoppe la saisie. Chacun valorise la propriété publique "Choice" pour permettre à la procédure appelante de savoir quel bouton a été cliqué. Lors de la validation, on vérifie que la personne a été choisie. Si ok, le formulaire est masqué et la procédure appelante reprend la main. Sinon, on ne sort pas du formulaire. Le bouton Cancel permet de masquer le formulaire et de stopper le cycle.

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
Option Explicit
 
Public Choice As String
 
Private Sub btnCancel_Click()
  Choice = "Cancel"
  Me.Hide
End Sub
 
Private Sub btnValidate_Click()
  If DatasAreOk Then
    Choice = "Validate"
    Me.Hide
  Else
    MsgBox "Veuillez choisir la personne dont il faut modifier les données"
  End If
End Sub
 
Function DatasAreOk() As Boolean
  DatasAreOk = ComboBox1.Value <> ""
End Function

La procédure appelante, placée dans un module standard, va appeler le formulaire, puis lorsqu'elle reprend la main, tester le bouton cliqué du userform puis traiter les données s'il y a lieu. Après quoi, le formulaire est déchargé puis affiché à nouveau, jusqu'à ce qu'on clique sur Annuler...

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
Sub ManagaData()
  Dim Result As String
  Dim Cell As Range
 
  Do
    With UserForm1
      .Show
      Result = .Choice
      If Result = "Validate" Then
        If .ComboBox1.Value <> "" Then
          Set Cell = Sheets("Source").Cells(.ComboBox1.ListIndex + 2, 1)
          Cell(1, 10).Value = .TextBox1.Value
          Cells(1, 1).Value = .ComboBox1.Value
          Cells(1, 12).Value = .TextBox2.Value
          Cells(1, 13).Value = .TextBox3.Value
          Cells(1, 14).Value = .TextBox4.Value
          Cells(1, 15).Value = .TextBox5.Value
          Cells(1, 16).Value = .TextBox6.Value
          MsgBox "Modifications effectuées"
        End If
      End If
    End With
    Unload UserForm1
  Loop While Result = "Validate"
End Sub

Au passage:

• Nommer correctement tes contrôles et ton formulaire ne coûte pas plus cher et rendra ton code plus lisible et maintenable;
• Es-tu bien certain que pour la cellule qui reçoit la valeur du combo, il s'agit bien de Cell(1,1)? Ne s'agirait-il pas plutôt de cell(1,11)?
• Tu gagnerais à travailler avec des tables de données. Ce serait plus simple et plus sécurisant pour le transfert;
• Comme tu le vois dans mon code, le Select n'est pas nécessaire. Il le serait encore moins avec une table de données.

[Invité]

si il fait Unload UserForm1 puis UserForm1.Show 0 c'est parce qu'il espère que le déchargement puis le rechargement de son formulaire réinitialisera ses contrôles! c'est qu'il n'a pas les mots c'est tout!

[Pierre Fauconnier]

La solution que je propose fait exactement ce que le demandeur souhaite. Elle décharge le formulaire et le recharge, forcément nettoyé. Mais elle propose une architecture qui permet cela facilement, en proposant également une manière de travailler plus générique et qui tend vers une architecture "trois-tiers".

A minima, même sans mettre en place une architecture "trois tiers", ce qui n'est pas compliqué et simplifierait énormément le code, il faut distinguer les responsabilités de chaque partie du code. Comme je l'ai dit, le userform n'a pas la responsabilité de transférer les données en DB (dans ce cas, la DB est la feuille Excel). Sa seule responsabilité est de vérifier qu'on a saisi ce qui est nécessaire à la bonne suite des opérations. Le formulaire, en tant que tel, n'a rien d'autre à faire. C'est simplement une "brique logicielle" qui assure la saisie des données par l'utilisateur. On devrait en fait pouvoir l'enlever et la remplacer par une autre qui lirait les donnés dans un fichier TXT, par exemple. Pouvoir réaliser cela prouverait que le code est bien construit, sur une architecture saine qui va permettre son évolution.

Si tu examines le code que je fournis, tu verras qu'il permet à l'utilisateur de faire exactement ce que le demandeur souhaite: Saisir des données au kilomètre en vidant le formulaire après chaque saisie. Il faut évidemment déterminer une sortie de boucle, ce qui est fait par la condition While en fin de boucle.

Essaie le code que j'ai donné et observe le résultat. Tu verras que cela fait exactement ce que le demandeur souhaite. La tienne le fait aussi, mais imagine ta solution lorsqu'il y a une centaine de contrôles à nettoyer, en ce compris des listbox multiselect et autres joyeusetés. Le code que je donne nettoie complètement le formulaire, sans devoir l'adapter aux contrôles présents dans le formulaire, et il le restitue pour la saisie suivante dans le même état que lors du premier affichage. Ton code vide les textbox mais rien ne dit qu'ils étaient vides à l'initialisation, dans une approche générique. C'est pour cela que j'insiste tant sur l'architecture du code et sur l'unique responsabilité d'une fonction...

[...]

si il fait Unload UserForm1 puis UserForm1.Show 0 c'est parce qu'il espère que le déchargement puis le rechargement de son formulaire réinitialisera ses contrôles! c'est qu'il n'a pas les mots c'est tout!

Le déchargement et le rechargement font EXACTEMENT ce qu'il souhaite, mais il faut les mettre au bon endroit, c'est-à-dire à l'extérieur du userform... En fait, sur le fond, je n'ai fait que répondre à sa question "pourquoi ça plante" et comment y remédier

[Invité]

Le déchargement et le rechargement font EXACTEMENT ce qu'il souhaite, mais il faut les mettre au bon endroit, c'est-à-dire à l'extérieur du userform...

On est bien d'accord la réponse est au poste #2!

[Pierre Fauconnier]

[...]
On est bien d'accord la réponse est au poste #2![...]

Ben non, on n'est pas d'accord. Au post #2, tu ne décharges pas pour recharger après, puisque tu as commenté les lignes... Tu vides les contrôles et tu fais cela dans le module du formulaire. Et si tu as 100 contrôles, tu écris 100 lignes à la suite? Et tu dois modifier ta proc de nettoyage si tu supprimes ou ajoute un contrôle?

Il faut juste réinitialiser les contrôles !

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
ComboBox1.ListIndex =-1
TextBox1.Value=""
TextBox2.Value=""
TextBox3.Value=""
TextBox4.Value=""
TextBox5.Value=""
TextBox6.Value=""
'Unload UserForm1
'UserForm1.Show 0
End Sub

Teste le fichier suivant, tu verras qu'il fait exactement ce que le demandeur souhaite.

Le code du userform ne fait qu'afficher les données du contact choisi, et détermine sur quel bouton on a cliqué. La vérification consiste, comme dans le post initial, à vérifier que l'on a choisi un contact.

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
28
29
30
Option Explicit
 
Public Choice As String
Public LoadDatasFunction As String
 
Private Sub btnCancel_Click()
  Choice = "Cancel"
  Me.Hide
End Sub
 
Private Sub btnValidate_Click()
  If DatasAreOk Then
    Choice = "Validate"
    Me.Hide
  Else
    MsgBox "Veuillez choisir la personne dont il faut modifier les données"
  End If
End Sub
 
Function DatasAreOk() As Boolean
  DatasAreOk = cboID.Value <> ""
End Function
 
Private Sub ComboBox1_Change()
 
End Sub
 
Private Sub cboID_Change()
  Run LoadDatasFunction
End Sub

On voit que le combobox appelle une procédure externe (ce n'est pas le rôle du userform d'aller lire en BD) pour charger les données du contact choisi. Le code d'un module standard qui va gérer tout cela est mis ci-dessous. (Attention, supprimer le * dans [Code*], car ajouté pour un problème de balises sur le forum)

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
28
29
30
31
32
33
34
35
Option Explicit
 
Sub ManagaData()
  Dim Result As String
  Dim Cell As Range
 
  Do
    With usfContact
      .cboID.List = Range("t_Contacts[Code*]").Value
      .LoadDatasFunction = "LoadDatas"
      .Show
      Result = .Choice
      If Result = "Validate" Then
        If .cboID.Value <> "" Then
          Set Cell = Range("t_Contacts[Code*]")(.cboID.ListIndex + 1, 1)
          Cell(1, 0).Value = .tboFirstName.Value
          Cell(1, 2).Value = .tboLastName.Value
          MsgBox "Modifications effectuées"
        End If
      End If
    End With
    Unload usfContact
  Loop While Result = "Validate"
End Sub
 
 
Sub LoadDatas()
  Dim Cell As Range
 
  With usfContact
    Set Cell = Range("t_Contacts[Code*]")(.cboID.ListIndex + 1)
    .tboFirstName.Value = Cell(1, 0).Value
    .tboLastName.Value = Cell(1, 2).Value
  End With
End Sub

Teste le fichier joint. Ne permet-il pas de réaliser ce que le demandeur souhaite? N'est pas plus propre que de nettoyer chaque contrôle du userform? Est-ce que cela ne correspond pas mieux à une architecture professionnelle, maintenable et évolutive?

Dysorthographie, franchement, je suis ouvert à la critique. Si tu veux démolir ma solution sur le plan technique, n'hésite pas, mais en argumentant stp.

[Invité]

Tu continue à dire des âneries,une il n'y a pas 100 contrôles et le cas échéant vba est là pour éviter décrire 100 lignes ou plus.

Perso j'ai jamais mis 100 contrôles sur un formulaire mais tu fais comme tu veux !

[Pierre Fauconnier]

Il serait sage de tester le code donné plutôt que de parler d'âneries. Evidemment qu'il n'y a pas 100 contrôles, actuellement. Mais si on laisse le demandeur avec ta solution pour 5 contrôles, il l'appliquera forcément lorsqu'il en aura 10, 20, 50 ou 100, et il placera autant de lignes dans la proc de nettoyage qui, soit dit en passant n'existe pas, tout se faisant dans l'événement CommandButton1_Click, ce qui n'est pas très propre.

La clé, en informatique et particulièrement en programmation, c'est la systématisation. Trouver la meilleure technique de codage, puis s'y tenir, qu'il y ait 5 contrôles ou qu'il y en ait 100. Sinon, c'est quoi la limite? 6 contrôles, 10 contrôles, 20 contrôles? C'est absurde de coder au p'tit bonheur. Je le répète, la clé, c'est la systématisation.

Et quitte à passer pour un dickenek (mec au gros cou), je persiste à dire que ma solution est la meilleure, parce qu'elle est générique, qu'elle tend vers les design pattern généralement utilisés en programmation ("trois tiers", "responsabilité unique de fonction", ...) qui ont été inventés et étudiés bien avant moi (je n'ai rien inventé) et qui ont plus que largement fait leurs preuves.

Et ces techniques, mon code et le classeur que j'ai joint le prouvent, ne sont ni difficile à comprendre, ni difficiles à mettre en oeuvre. Je te demande depuis tout à l'heure d'argumenter la technique, mais je ne vois rien venir... Tu parles juste d'âneries mais j'attends des arguments techniques qui démontent ma solution.

[Invité]

Ecoutes tu raison ta solutions ait merveilleuse on décharge le formulaire puis on le recharge pour ne pas réinitialiser les contrôles.

[Pierre Fauconnier]

Argumente stp...

Et réponds à ma question: Que feras-tu lorsque tu auras plus de contrôles? Tu sais comme moi que ceux qui postent sur les forums postent une partie de leur "solution"... Qu'est-ce qui permet de croire qu'au final, il n'y aura pas beaucoup plus de contrôles? Qu'est-ce qui permet de déterminer la limite à partir de laquelle il vaudrait mieux recharger que vider les contrôles?

Et puisque tu sembles trouver qu'il vaut mieux vider les contrôles que de décharger/recharger, ARGUMENTE et prouve que ça vaut mieux. Dis en quoi ta technique est meilleure que la mienne...

Ca va plus vite? Prouve-le, avec des tests sérieux... Et même si ça va plus vite, est-ce le seul critère? C'est peut-être le tien, mais qui dit que ce critère est le seul bon? Qui dit que c'est le mien? Qui dit que la vitesse est le seul critère valable? Et si tu penses que c'est stupide de décharger/recharger, dis en quoi... C'est ça le débat technique.

J'ai largement argumenté ma solution. Je pense qu'il est préférable de systématiser son approche et de respecter les architectures et design pattern définis pour les applications de gestion de données en stand alone. Tu peux parfaitement ne pas être d'accord avec cela, mais ne parle pas d'âneries. Avance tes arguments, défends-les sur le plan technique et nous pourrons débattre sereinement de la chose.

Dire ceci

[...]on décharge le formulaire puis on le recharge pour ne pas réinitialiser les contrôles.[...]

en laissant croire que ma technique est débile sans l'argumenter, ça ne fait rien avancer du tout...

Parler d'erreurs sans les relever (alors que mon code est parfaitement fonctionnel) ne sert à rien. Encore une fois, argumente avec de la technique. Tu ne peux parler d'erreurs que si tu les mets en évidence. J'attends tes arguments.

[Invité]

Je ferais comme d'habitude,un formulaire ne peut en aucun cas contenir un nombre de contrôles ingérables.

Je ne remet pas en question tes compétences professionnelles ne remets pas les.mienne en cause stp.

Je ne suis pas un informaticien autodidactes !

en laissant croire que ma technique est débile sans l'argumenter, ça ne fait rien avancer du tout...

Je ne le laisse pas croire je l'affirme, et ça ne fait rien avancer du tout...
Décharge puis recharger un formulaire c'est absurde quel autre arguments as tu besoin ?

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
With UserForm1
      .Show
      Result = .Choice
      If Result = "Validate" Then
        If .ComboBox1.Value <> "" Then
          Set Cell = Sheets("Source").Cells(.ComboBox1.ListIndex + 2, 1)
          Cell(1, 10).Value = .TextBox1.Value
          Cells(1, 1).Value = .ComboBox1.Value
          Cells(1, 12).Value = .TextBox2.Value
          Cells(1, 13).Value = .TextBox3.Value
          Cells(1, 14).Value = .TextBox4.Value
          Cells(1, 15).Value = .TextBox5.Value
          Cells(1, 16).Value = .TextBox6.Value
          MsgBox "Modifications effectuées"
        End If
      End If
    End With
    Unload UserForm1
  Loop While Result = "Validate"

Ou réinitialises tu les contrôles car, même si la formulation du demandeur n'est pas la bonne, c'est bien de cela qu'il est question les TextBoxX.Value=""?

[Pierre Fauconnier]

[...]
Décharge puis recharger un formulaire c'est absurde quel autre arguments as tu besoin ?

Hmmm. J'attendais des arguments, j'ai juste "c'est absurde" dans aucune explication. Que n'as-tu pas compris dans "argumenter"?

[...]
Ou réinitialises tu les contrôles car, même si la formulation du demandeur n'est pas la bonne, c'est bien de cela qu'il est question les TextBoxX.Value=""?

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.

Par ailleurs cette question ("Où réinitialises-tu les contrôles...?") est d'une stupidité affligeante, puisque notre escarmouche tourne justement autour de cela. Si tu avais testé la solution que j'ai proposée, même peut-être seulement lire, et comprendre, le code que j'avais donné, tu verrais où les contrôles sont réinitialisés... Dans le code que j'ai donné pour la procédure ManageData du message #7, la ligne qui réinitialise est celle qui décharge le formulaire (la ligne numérotée 22 Unload usfContact).


Manifestement, tu ne sembles pas avoir compris comment fonctionne un formulaire ni quel est son cycle de vie alors, sinon, tu saurais que le Unload décharge le formulaire, et donc, lorsqu'il est rechargé, il se présente tel qu'il a été programmé (et donc avec les valeurs par défaut, et pas forcément des "")...

Dans le message #7, je donne le code de la procédure ManageData qui, au départ d'un module standard, dans une boucle

• charge le formulaire
• alimente la liste déroulante
• affiche le formulaire
• traite les données si besoin pour les envoyer dans la table;
• décharge le userform => initialise les contrôles (notamment, vide les textbox);
• recharge le formulaire.

La boucle s'arrêtant lorsque l'utilisateur clique sur le bouton Annuler du formulaire. J'ai expliqué que cette architecture permettait de ne pas devoir nettoyer individuellement chaque contrôle. Il n'est donc pas nécessaire de modifier la procédure de nettoyage puisque Unload FAIT le nettoyage. Ca signifie que si tu ajoutes des contrôles, cette partie du code ne doit pas être modifiée, tu ne dois pas ajouter x lignes pour nettoyer les x nouveaux contrôles ajoutés... (surtout que ce n'est pas toujours x lignes, car déselectionner les items d'un listbox, c'est une petite boucle...), etc, etc, etc...


Evidemment, pour pouvoir critiquer intelligemment et répondre sur le plan technique, il aurait fallu que tu lises mon code, que tu le comprennes, que tu le testes. Ce que tu n'as manifestement pas fait. Tu parles donc dans le vide et tu poses une question stupide ("Ou réinitialises tu les contrôles") alors que si tu avais pris la peine de comprendre ma réponse, cette question aurait été superflue.

J'ai dit également pourquoi je considérais cette solution comme la meilleure. J'ai argumenté, et en retour, je n'ai aucun argument, juste ceci

[...]
Décharge puis recharger un formulaire c'est absurde quel autre arguments as tu besoin ?

Pourquoi est-ce absurde? Quels sont les arguments avancés? Pourquoi vider chaque contrôle et donc devoir modifier la proc si ajout ou suppression de contrôle est meilleure qu'un Unload,...? Rien, nada, nuts, le vide, le néant,... Juste "c'est absurde" ou "tu dis des âneries"...

De plus en plus pitoyable

[Invité]

Que ton code fonctionne ok peut importe, que le mien peut mieux faire sens aucun doute!

Seul le formulaire est utile il est ouvert, la methode de notre amis pour mètre à jour excel est convenable dans le contexte qui pour le coup ne te gène pas alors si il avait 100 contrôles mais je passe.

En fait son code suffirait presque il ne lui manque que ce que je décris au poste #2 à oui les 100 contrôles qui ne te gêne pas dans un sens te gêne dans l'autre. Au niveau cohérence j'ai connu mieux.

Il veau mieux un code farfelu et ésotérique ! Pourquoi pas 4 module de classes?

[Pierre Fauconnier]

Dysorthographie,

Que ton code fonctionne ok peut importe, que le mien peut mieux faire sens aucun doute![...]

Essaie de comprendre ce que c'est une architecture et apprends à argumenter sur le plan technique, et on en reparle.

[...]la methode de notre amis pour mètre à jour excel est convenable dans le contexte[...]

Il faut arrêter de dire n'importe quoi. La "méthode de notre ami" n'est pas convenable puisqu'elle plante! C'est pour cela qu'il a créé la discussion. Et malgré tes dires, j'ai expliqué que le userform ne peut pas se décharger lui-même, arguments à l'appui.

[...]
Il veau mieux un code farfelu et ésotérique ! Pourquoi pas 4 module de classes?

Toujours des qualificatifs utilisés sans arguments (pourquoi farfelu, pourquoi ésotérique). Pourquoi parler de 4 modules de classe là où il y a une procédure qui appelle le formulaire et qui traite la saisie? Mystère, puisque tu n'argumentes rien. il n'y a AUCUN argument dans tes propos. Juste du dénigrement sans aucun fondement.

Tu n'as manifestement rien compris au code que j'ai proposé et tu continues à ânonner sans aucun argument technique. Tu sais juste dire "j'ai la plus grosse" sans dire pourquoi la tienne est la meilleure sur le plan technique... J'ai argumenté, expliqué, démontré, illustré. Tu t'es contenté de dire "tu dis des âneries", "le mien peut mieux faire sans aucun doute", "code farfelu et ésotérique" sans AUCUN argument technique... Juste du vent, de la daube.

[Invité]

J'ai lue attentivement tout ce que tu as posté sur ce fils code comprit et je n'ai vue aucun arguments techniques.

Je te laisse, pour le coup,vraiment avec ton égo.

[Pierre Fauconnier]

Où as-tu lu, dysorthographie, que recharger le formulaire était équivalent à textbox1.value = ""... Où as-tu lu, dans la demande initiale, que les textbox devaient être vidés... Nulle part dans le code initial, il est dit que les textbox doivent être vidés... NULLE PART... Le post parle juste d'un unload qui pose problème (parce que initié par le formulaire et donc impossible à réaliser puisque le formulaire ne peut pas se décharger lui-même...). La demande initiale porte donc sur le fait de pouvoir décharger puis recharger un formulaire...

Et si un des textbox, au chargement du formulaire, était initialisé avec la date courante, par exemple, que va faire ton code? Vider le textbox... Recharger le formulaire permettrait de récupérer la date courante, et donc, de préparer la saisie suivante... Au demeurant, c'était la demande initiale (unload => Show) que tu as toi-même soulignée dans un de tes posts, et que ton code ne réalise pas... puisque tu as décommenté les lignes... Mais je suppose que ce n'est pas un argument technique, bien sûr...

C'est pour cela que je parle de code générique, de systématisation. Si, après une saisie, on doit vider le formulaire et le préparer pour la saisie suivante, il me semble logique de le décharger puis de le recharger...

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.

[Patrice740]

Bonjour Pierre,

Le post parle juste d'un unload qui pose problème (parce que initié par le formulaire et donc impossible à réaliser puisque le formulaire ne peut pas se décharger lui-même...).

Sans m’immiscer dans la discussion précédente, je suis surpris de ton affirmation : le formulaire ne peut pas se décharger lui-même.
Je sais que le formulaire ne peut pas se [re]charger lui-même mais je n'ai jamais eu de problème pour qu'un formulaire se décharge.
J'étais même surpris qu'une macro de ce formulaire ne s'interrompe pas dès que le déchargement est effectif, par exemple :

Code :

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

1
2
3
4
5
Private Sub CommandButton1_Click()
    Unload UserForm1
    MsgBox "UserForm1 déchargé"
    UserForm2.Show
End Sub

[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