Discussion :

[Pierre Fauconnier]

Ben oui... Forcément. Si on décharge le formulaire, on perd les valeurs des contrôles du userform

C'est pourquoi le bouton de validation du userform ne contient pas unload me mais me.hide, ce qui fait que le usf reste chargé et qu'on peut utiliser les valeurs des contrôles (et toutes les autres propriétés du usf, d'ailleurs).

Si tu as unload me sur le bouton de validation (dans le module du usf, donc), puis que tu appelles une propriété du usf (après qu'il soit déchargé, donc), par exemple userform1.textbox1.Value, tu vas implicitement charger une nouvelle fois le userform avec, bien entendu, ses valeurs par défaut qui ne seront forcément pas celles saisies par l'utilisateur.

Prends le temps de regarder en pas à pas le code que j'ai donné dans mon premier message en saisissant des données dans les textbox, puis modifie me.hide en unload me et refais l'opération en pas à pas. Tu verras bien qu'avec me.hide, le usf n'est plus visible mais tu récupères bien les données saisies, alors qu'avec unload me, non seulement tu as perdu les valeurs saisies, mais en plus, tu as à nouveau chargé le formulaire.

[Pierre Fauconnier]

[...]

reste aussi au final qu'il peut simplement tester la valeurs des textboxs de ces userforms si elles ne doivent absolument pas etre vides

puisque l'on peut tester la valeur d'un textbox meme si il n'est pas loader

Non. Ce n'est pas possible de tester la valeur d'un textbox d'un usf non chargé. Comment voudrais-tu que cela soit possible? C'est justement là la pertinence des remarques de Marc et de Jacques. Lis la discussion et les exemples qui sont donnés, stp.

Si tu essaies de tester la valeur d'un textbox d'un usf non chargé, VBA va d'abord charger le usf puis te donner la valeur de la propriété souhaitée (qui sera donc la valeur par défaut, c'est-à-dire celle qui a été prévue par le concepteur du usf, en dur ou dans le Initialize du USF). Et ce ne sera donc jamais celle saisie par l'utilisateur puisqu'il n'a pas encore pu saisir une donnée.

Je crois que ce qui te bloque, c'est que tu as l'habitude de tout faire au sein d'un usf, mais c'est une démarche qui n'est pas professionnelle.

1. Tu fais un usf.show;
2. tu y saisis des données et/ou tu en récupères d'ailleurs (feuille excel ou autre);
3. tu traites les données à l'intérieur du usf;
4. tu décharges le usf.

Cette manière de procéder n'est, à mon estime, pas la bonne. Elle crée une dépendance forte entre ton usf et l'environnement dans lequel il se trouve. Si, pour une raison x, l'environnement est modifié, ton usf est tout cassé.


C'est pourquoi j'ai parlé des trois états d'un usf et que mon code illustre ce qui, pour moi à nouveau, est la bonne marche à suivre:

1. chargement du usf (optionel, mais je préfère);
2. passage des valeurs à transmettre aux contrôles du usf si besoin;
3. affichage du userform;
4. Saisie des données par l'utlisateur;
5. Masquage du userform;
6. Récupération des données;
7. Décharge du userform de la mémoire.

Avec cela, ton userform n'est plus du tout dépendant de son environnement. C'est pourquoi je préconise cette manière de procéder.

[patricktoulon]

re

[userform1.textbox1.Value, tu vas implicitement chargé une nouvelle fois le userform avec, bien entendu, ses valeurs par défaut qui ne seront forcément pas celles saisies par l'utilisateur

a bon????

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
'userform1.textbox1.Value, tu vas implicitement chargé une nouvelle fois le userform avec, bien entendu, ses valeurs par défaut qui ne seront forcément pas celles saisies par l'utilisateur.
'?????????
Sub affiche()
With UserForm1
.Show 0
.TextBox1 = "coucou"
End With
End Sub
 
Sub test1()
' sans afficher le userform
MsgBox UserForm1.TextBox1.Text
End Sub
 
Sub test2()
' avec affichage du userform
affiche
MsgBox UserForm1.TextBox1.Text
End Sub
 
Sub test3()
' avec affichage du userform puis  hide
affiche
UserForm1.Hide
MsgBox UserForm1.TextBox1.Text
End Sub

a moins que l'on se soit mal compris en aucun cas "msgbox userform1.textbox1.text "donne les valeurs par defaut la preuve ci dessus c'est bien pour ca que j'ai sepaé les msgbox du show de l' usf

[Pierre Fauconnier]

re

a bon????

Ben... Je ne vois pas en quoi tes exemples contredisent ce que j'ai dit...


A aucun moment, tu ne décharges le formulaire, donc forcément, msgbox affiche coucou à tous les coups.

Si tu exécutes Test1 après l'une des autres procédures, tu auras aussi forcément coucou, puisque le formulaire est chargé

Ce n'est pas qu'on ne s'est pas compris, c'est que tu ne comprends pas ce que je t'explique. Relis mes propos calmement et teste mon code, ça t'aidera à mieux comprendre le mécanisme à mettre en place

[Pierre Fauconnier]

re

a bon????

'userform1.textbox1.Value, tu vas implicitement chargé une nouvelle fois le userform avec, bien entendu, ses valeurs par défaut qui ne seront forcément pas celles saisies par l'utilisateur.[...]

Tu ne peux évidemment pas sortir la phrase citée de son contexte.

[...]

Si tu as unload me sur le bouton de validation (dans le module du usf, donc), puis que tu appelles une propriété du usf (après qu'il soit déchargé, donc), par exemple userform1.textbox1.Value, tu vas implicitement charger une nouvelle fois le userform avec, bien entendu, ses valeurs par défaut qui ne seront forcément pas celles saisies par l'utilisateur.

J'ai parlé de trois étapes: Unload du usf, puis appel d'une propriété du usf qui implique (d'où l'utilisation du terme chargement implicite) un nouveau chargement avant l'affichage de la propriété. Dans ce contexte-là, tu n'auras pas coucou, tu auras la valeur par défaut donnée par le concepteur ou lors de l'initialisation du userform.

Arrête de répondre tête baissée sur ton clavier pour essayer d'avoir raison en prenant des exemples foireux. Prends simplement le temps de lire, de tester et de comprendre ce qui est dit ici

[patricktoulon]

re
dans mes exemple je n'ai pas de bouton j'ai testé avec un textbox
tu a dis " les valeurs par defaut" pour moi les valeur par defaut sont celle qui son inscrite en mode VBE ( quelque chose /ou vide)et quoi que cette notion de valeur par defaut est erronée pour moi

apres load d'un userform et incription de texte dans le textbox un msgbox userform1.textbox1.text ne te donnera pas la valeur par defaut mais bien celle qui est presente dans le textbox
meme si ce msgbox est dans une sub dans un module standard ou ailleurs comme tu veux et que le userform soit en hide ou affiché
par contre apres unload le textbox et bien dechargé et c'est la valeur par defaut ,quoi que la!! on pourrait se poser la question si la notion de valeur par defaut est a utiliser

car ici au final userform affiché,hide ou unloadé

userform1.textbox1.text donne la valeur actuelle inscrite textbox et puis c'est tout; en prenant bien evedement en compte que le unload du userform remet la valeur initiale dans le textbox ( celle qui est presente en mode VBE)

un textbox a une propriété ".text" et non ".defaultValue"

d'ou ma reflexion sur ce point tout a l'heure :peut etre que le teste(dans son code initial en post1) doit se faire plutot sur les valeurs des textboxs et non la presence ou non des userforms

tu disais tout a l'heure que le simple fait d'interroger le ".text" chargait le userform" ce dont je doute puisque je peux interroger sans meme avoir toucher le userform

on pourrait alors dire aussi que le unload en fait autant

puisque en mode VBE ayant "toto" inscrit dans le textbox et inscrivant "titi"en mode show/visible et en le unloadant l'interrogation me donnerait "toto"

je dis ca justement car on a pas de propriété "defaultValue"pôur le textbox donc seule la notion de chargé /(re/dé)chargé est alors a debattre sur ce point et sur le userform pas sur le reste


petit test sans loader le userform le unload a la fin recharge le userform a l'origine bien qu'il n'ai pas été loadé ou show

mais il est nullement question de "valeur par default"cette propriété n'existe pas

Code :

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

1
2
3
4
5
6
7
8
Sub test2()
' sans affichage du userform
Debug.Print UserForm1.TextBox1.Text
UserForm1.TextBox1.Text = "titi"
Debug.Print UserForm1.TextBox1.Text
Unload UserForm1
Debug.Print UserForm1.TextBox1.Text
End Sub

dans l'exemple ci dessus si tu enleve le unload tu aura "titi" et non la valeur par defaut comme tu dis donc l'interrogation de remetpas les valeurs par defaut

bref ces notion de charge/(decharge/recharge) les deux derniers sont un peu floues tout du moins dans l'interprétation

[unparia]

Cela peut durer longtemps.
Il n'y a absolument rien de flou --->>

Code :

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

1
2
3
4
5
msgbox UserForm1.TextBox1.Text '--->> évocation du userform -->> placé dans la collection userforms et donc accessible, avec ses valeurs de création
UserForm1.TextBox1.Text = "titi" ' --->> accessible ? -->> on peut modifier la textbox
MsgBox UserForm1.TextBox1.Text ' --->> toujours accessible ? --->> on peut lire le contenu de la textbox dans une variable
Unload UserForm1 ' --->> on le supporime de la collection userforms ? --->> il n'est plus accessible et retrouve ses valeurs de création
MsgBox UserForm1.TextBox1.Text '--->> de nouveau accessible (évocation du userform et donc dans userforms à nouveau) -->> textbox1.text retrouve ses valeurs de création

Il suffit de comprendre que toute évocation d'un userform existant parmi les composants du projet ajoute celui-ci à la collection userforms.
Même cette simple instruction l'y ajoute :

Code :

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

1
2
3
MsgBox UserForms.Count
 Set k = UserForm1
MsgBox UserForms.Count

EDIT : il suffit de se rappeler que le verbe To Load a un sens transitif et un sens intransitif.
Dans l'expression :
Load UserForm1
on ne "charge" pas le Userform, mais la collection Userforms par Usrerform1

[Pierre Fauconnier]

Si tu fermes le useform avec la croix, tu le décharges. Tu ne sais dès lors plus rien exploiter de ce userform. Il est mort. Fini, envolé de la mémoire à tout jamais. Une partie de ton incompréhension vient peut-être de là, de cette utilisation de la croix pour fermer puis traiter le usf alors que l'ergonomie de Windows veut que la fermeture d'une boite de dialogue par la croix décharge la boite de dialogue de la mémoire et fasse comme si elle n'avait jamais été ouverte. il ne peut donc rien se passer après la fermeture d'un usf de cette manière. Tout test sur le usf après une telle fermeture ne rime à rien. C'est le b.a.ba de Windows, ça.

C'est aussi pour cela que je n'aime pas que les traitements soient effectués par le code du usf et que je propose d'utiliser le mécanisme que j'expose dans ma toute première réponse. Ce n'est pas dans les règles ergonomiques de Windows. Si je ferme un usf avec la croix, c'est justement pour que rien ne se passe après. On apprend cela après une heure de formation Windows de base. Et toi, tu vas foutre plein de traitements de données et tout et tout dans le code du usf. Et si après la personne veut fermer le usf avec la croix, persuadée que rien ne sera modifié => bardaf c'est l'embardée. Ce n'est pas de la pensée unique, ce dont je te parle ici. Je te parle du respect des standards Windows pour une programmation professionnelle.

C'est pourquoi j'ai mis un bouton avec comme code me.hide. Ainsi, le userform reste chargé jusqu'à un éventuel unload usf. C'est pour respecter les standards, pour que l'utilisateur soit face à un comportement attendu par lui selon la façon dont il ferme le usf et que, si traitement il y a, il soit effectué hors du userform qui n'est jamais (qui ne devrait jamais être) qu'un instrument d'affichage et de capture d'info (hormis les boites de dialogue qui gère les options d'une application et qui ont en général un bouton Appliquer en plus des boutons Ok et Annuler, mais qui par nature sont fortement liées à l'application ou au fichier).

Toute la démonstration, et toute la bonne utilisation d'un userform tourne autour de cela. Si tu prends tout le temps des exemples foireux en modifiant certaines parties de code n'importe comment, forcément, tu ne comprendras rien

tu a dis " les valeurs par defaut" pour moi les valeur par defaut sont celle qui son inscrite en mode VBE ( quelque chose /ou vide)[...]

Oui, mais pas que. Elles peuvent aussi être déterminées par code au sein de la proc Initialize. Et elles peuvent aussi ne pas être modifiées par le concepteur du usf, auquel cas ce sont les valeurs par défaut prévues par Microsoft qui sont affectées aux contrôles. Et ce n'est pas "quelque chose ou vide". C'est, dans le cas d'un textbox, quelque chose ou chaine vide (=""). dans le cas des checkbox, c'est False par défaut, ...

apres load d'un userform et incription de texte dans le textbox un msgbox userform1.textbox1.text ne te donnera pas la valeur par defaut mais bien celle qui est presente dans le textbox

Je n'ai jamais dit le contraire. C'est JUSTEMENT ce que je démontre dans mon tout premier message.

meme si ce msgbox est dans une sub dans un module standard ou ailleurs comme tu veux et que le userform soit en hide ou affiché
par contre apres unload le textbox et bien dechargé et c'est la valeur par defaut[...]

Après le Unload, le textbox est effectivement déchargé, et donc, ce n'est pas la valeur par défaut. Il n'y a plus de valeur puisqu'il n'y a plus de textbox (déchargé = mort, disparu, volatilisé, inexistant)

userform1.textbox1.text donne la valeur actuelle inscrite textbox et puis c'est tout; en prenant bien evedement en compte que le unload du userform remet la valeur initiale dans le textbox ( celle qui est presente en mode VBE)

Mais non, le Unload ne remet pas la valeur initiale. Le Unload décharge le usf. Il n'y a plus de textbox après cela. Il est mort, parti de la mémoire, comme tout ce qui constituait le userform. Il n'y a pas de valeur initiale qui pourrait être remise dans le textbox puisque le textbox n'existe plus. C'est notamment cela que tu ne comprends pas. Et c'est parce que tu ne comprends pas cela que tu ne comprends pas que le userform est automatiquement chargé en mémoire s'il ne l'était pas lors de la lecture d'une propriété du usf. Si le usf n'était pas chargé, il ne saurait pas y avoir de lecture du textbox.value puisqu'il n'y aurait pas de textbox (ni de usf).

un textbox a une propriété ".text" et non ".defaultValue"

Je n'ai jamais dit qu'un textbox avait un .defaultvalue. J'ai dit qu'un textbox a une valeur par défaut, ce qui est très différent. Cette valeur est précisée en dur à la conception ou par code dans le Initialize. Si rien n'est précisé, sa valeur par défaut est une chaine vide ""

tu disais tout a l'heure que le simple fait d'interroger le ".text" chargait le userform" ce dont je doute puisque je peux interroger sans meme avoir toucher le userform

On s'en fout que tu en doutes Que tu en doutes ne change rien au fait que s'il n'est pas chargé, la lecture ou l'affectation d'une propriété du usf le charge avant d'exploiter la propriété. Jacques en a fait la démo tout à l'heure en manipulant la collection Userforms. Tu ne saurais pas interroger une propriété du usf sans y toucher. C'est tout simplement impossible. Je l'illustre ici




Tu peux encore t'en convaincre avec le test suivant, qui te montre que rien que le fait de tester userform1 is nothing le charge avant de tester qu'il soit nothing, puisque le test renvoie False et qu'après, la collection des userforms a gagné un élément.

on pourrait alors dire aussi que le unload en fait autant

Ca veut dire quoi "en fait autant"? Le Unload décharge l'objet de la mémoire. On ne peut donc plus l'utiliser. Conceptuellement, ça correspond à un = Nothing sur un objet, même si je viens de te démontrer qu'un userform ne saurait pas être nothing.

puisque en mode VBE ayant "toto" inscrit dans le textbox et inscrivant "titi"en mode show/visible et en le unloadant l'interrogation me donnerait "toto"

Ca fait je ne sais pas combien de messages que c'est ce que j'essaie de t'expliquer.

je dis ca justement car on a pas de propriété "defaultValue"pôur le textbox donc seule la notion de chargé /(re/dé)chargé est alors a debattre sur ce point et sur le userform pas sur le reste

Il n'y a RIEN à débattre. De quoi veux-tu débattre? Il n'est pas question ici de donner un avis "je pense que...", "il me semble". Il est question d'une réalité technique tangible, mesurable, qui peut être vérifiée, comme nous te l'avons déjà montré Jaques et moi. Tu as juste à admettre que l'exploitation d'une propriété d'un userform le charge d'abord en mémoire s'il ne l'est pas déjà. Comment voudrais-tu aller chercher une propriété d'un objet non chargé? Si le usf n'était pas chargé en mémoire, tu aurais une erreur de type Objet is nothing ou quelque chose du genre (ce qui est impossible, voir plus haut). Or, tu récupères bien la valeur par défaut. C'est donc bien la preuve que l'objet a été chargé AVANT de te donner la valeur de la propriété.

En fait, un usf peut être chargé de quatre façons (pour détailler):

1. de façon explicite avec load usf;
2. de façon implicite par la lecture d'une propriété du usf même s'il n'est pas chargé (debug.print usf.textbox1.value);
3. de façon implicite par l'affectation d'une valeur à une propriété du usf même s'il n'est pas chargé (usf.textbox1.value = "coucou");
4. de façon implicite par l'utilisation d'une méthode du usf même s'il n'est pas chargé (usf.show).

Les trois façons implicites impliquent le chargement du usf avant exécution de la ligne de code.

petit test sans loader le userform le unload a la fin recharge le userform a l'origine bien qu'il n'ai pas été loadé ou show

MAIS SI. IL A ETE CHARGE... Il est IMPOSSIBLE de tester quoi que ce soit d'un userform sans le charger. C'est I M P O S S I B L E. Que tu le veuilles ou non, c'est ainsi. La ligne de ton code Debug.Print UserForm1.TextBox1.Text CHARGE le userform S'IL NE L'EST PAS. Si tu ne comprends pas cela, tant pis, mais ACCEPTE-LE. C'est ainsi que ça se passe. Point final. Rien à débattre là-dessus.

Et le unload à la fin NE RECHARGE RIEN à l'origine comme tu l'énonces. Unload veut dire Décharger. Comment en arrives-tu à dire que Unload recharge?

Si tu veux savoir s'il y a un chocolat emballé dans du papier rouge dans une boite de chocolats, tu dois bien ouvrir la boite, non? Ben avec un userform, c'est la même chose. Si tu veux connaître la valeur d'une propriété d'un userform, tu dois d'abord le charger en mémoire. Et le VBA étant permissif, si tu n'as pas ouvert la boite de chocolats, il l'ouvre pour toi si tu lui demandes la couleur de l'emballage des chocolats qui sont dedans.

On n'a pas besoin de tous tes tests. On s'en fout. Ils ne servent à rien. Tu écris des tests foireux pour qu'ils correspondent à ce que tu souhaites démontrer.

TU as besoin d'accepter, à défaut de le comprendre, qu'un userform est forcément chargé avant que tu en exploites une propriété quelle qu'elle soit, et que lorsqu'il est déchargé, tu ne sais rien en faire ni en lire aucune propriété. Et donc, que si tu en lis une propriété alors que tu ne l'as pas chargé (absence de Load), c'est forcément qu'il a été chargé juste avant de te donner la valeur de la propriété, sans que tu l'aies explicitement demandé. C'est le comportement normal des usf tel que souhaité par les concepteurs du VBA. Que tu sois d'accord ou pas, que tu le comprennes ou pas, c'est comme ça.

Et c'est notamment parce que des gens comme toi ne comprennent pas le chargement implicite du userform que je préfère que le code le charge explicitement avec Load.

[nouhaaa1995]

ouii, exactement mes usf ont été unload, donc j'ai utilisé hide, et mon problème a été résolu
je vous remercie

[Pierre Fauconnier]

Plaisant que notre longue discussion t'ait permis de trouver une solution à ton problème...

[laurent_ott]

Pierre, au lieu de perdre ton énergie et ton calme sur cette discussion, je te propose de te relaxer en découvrant mon dernier mémento.
Cordialement.

[laurent_ott]

N'empêche que tes commentaires dans cette discussion mériteraient un tutoriel sur l'usage des formulaires dans Excel (userform) si ce n'est déjà fait ?

[unparia]

tes commentaires dans cette discussion mériteraient un tutoriel sur l'usage des formulaires dans Excel (userform) si ce n'est déjà fait

Ce serait peut-être en effet (on le voit bien) une bonne idée.
Une suggestion, si la chose devait être faite : lever toute ambiguïté en traduisant le verbe "to load" autrement que par "charger" ("embarquer", peut-être ?)

EDIT et NB : l'adverbe "expressément" est un joli adverbe.
Il est dommage que sa traduction en anglais (expressly) n'a pas tou(t/s) le(s) même(s) sens. L'adverbe "expressly" est d'ailleurs très rarement utilisé par les anglophones, qui, eux, emploient généralement l'adverbe "explicitly"

[Transitoire]

Merci à tous de vos renseignements et d'avoir pris tant de temps et d'énergie pour illuminer les gens qui cherchent à comprendre.
Cordialement