Discussion :

[empiresailor]

Bonjour,

Je cherche à remplir un tableau excel en passant par plusieurs formulaires. J'ai donc dans le module :

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
36
37
38
39
40
41
42
43
44
 
Sub variables()
 
Dim var1 As Integer
Public A, B, C, D, E, F
 
End Sub
 
 
Sub enregistre()
 
    Dim EntreePlus As Worksheet, ZZ As Range, Erg, i As Integer, AA As Range, BB As Range, EE As Range, XX As Range, YY As Range, FF As Range, GG As Range
 
 
    Set EntreePlus = ThisWorkbook.Worksheets("Feuil1")
 
 Application.ScreenUpdating = True
 
 
 
    Set XX = EntreePlus.Cells(16384, 1).End(xlUp).Offset(1, 0) 'civilité
    Set ZZ = EntreePlus.Cells(16384, 2).End(xlUp).Offset(1, 0) 'nom
    Set YY = EntreePlus.Cells(16384, 3).End(xlUp).Offset(1, 0) 'prénom
    Set AA = EntreePlus.Cells(16384, 4).End(xlUp).Offset(1, 0) 'adresse
    Set BB = EntreePlus.Cells(16384, 5).End(xlUp).Offset(1, 0) 'code postal
    Set EE = EntreePlus.Cells(16384, 6).End(xlUp).Offset(1, 0) 'ville
 
 
    XX.Offset(0, i).Value = A
    ZZ.Offset(0, i).Value = UserForm004.TextBox3.Text
    YY.Offset(0, i).Value = C
    AA.Offset(0, i).Value = D
    BB.Offset(0, i).Value = E
    EE.Offset(0, i).Value = F
 
 
 
 
 
Application.ScreenUpdating = True
 
    MsgBox "Les données ont été enregistrées avec succés"
 
End Sub

Et dans le 1er Userform

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
 
Sub Image8_Click()
 A = "NCE01"
 B = UserForm004.TextBox4.Text
 C = ""
 D = ""
 E = UserForm004.TextBox3.Text
 F = UserForm004.TextBox2.Text
 
Module1.enregistre
End Sub

Un deuxième pour exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
 
Sub Image8_Click()
 A = "NCE02"
 B = ""
 C = "UserForm005.TextBox4.Text"
 D = ""
 E = UserForm005.TextBox6.Text
 F = UserForm005.TextBox2.Text
 
Module1.enregistre
End Sub

J'aimerai donc facilement pouvoir changer le contenu des variables A, B, C à intégrer au tableau selon le userform utilisé (16 au total). Si vous avez des idées ou si je suis pas clair hésitez pas !

Merci

[EricDgn]

Bonjour,

L'instruction Public ne doit pas être placée dans une routine, mais en tête du module.
Ceci devrait fonctionner:

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
Public A, B, C, D, E, F
 
Sub Enregistre()
    Dim EntreePlus As Worksheet, XX As Range
    Set EntreePlus = ThisWorkbook.Worksheets("Feuil1")
    Set XX = EntreePlus.Cells(16384, 1).End(xlUp)
    With XX
        .Offset(1, 0).Value = A 'civilité
        .Offset(1, 1).Value = B 'nom
        .Offset(1, 2).Value = C 'prénom
        .Offset(1, 3).Value = D 'code postal
        .Offset(1, 4).Value = E 'ville
    End With
    MsgBox "Les données ont été enregistrées avec succès"
    Set XX= Nothing
    Set EntreePlus = Nothing
End Sub

Bonne continuation.

[Patrice740]

Bonjour,

Les variables publiques sont à utiliser avec prudence, il est préférable d'utiliser des variables locales (niveau procédure) et de les transmettre en argument aux procédures appelées.
Pour faciliter la lecture du code il est aussi conseillé d'utiliser des nom de variables, d'objets, de procédure, ... représentatifs et préfixés
Exemple avec un type de variable personnalisé (on aurait aussi pu utiliser un tableau de string mais ce serait moins compréhensible) :

Dans un module standard :

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
Option Explicit
Public Type Untel
  Civilité As String
  Nom As String
  Prénom As String
  Adresse As String
  CP As String
  Ville As String
End Type
 
Public Sub Enregistre(Quidam As Untel)
Dim EntreePlus As Worksheet
  Set EntreePlus = ThisWorkbook.Worksheets("Feuil1")
  Application.ScreenUpdating = True
  With EntreePlus
    With .Cells(.Rows.Count, "B").End(xlUp).Offset(1) 'Colonne B (Nom) obligatoire
      .Offset(0, 0) = Quidam.Civilité
      .Offset(0, 1) = Quidam.Nom
      .Offset(0, 2) = Quidam.Prénom
      .Offset(0, 3) = Quidam.Adresse
      .Offset(0, 4) = Quidam.CP
      .Offset(0, 5) = Quidam.Ville
    End With
  End With
  Application.ScreenUpdating = True
  MsgBox "Les données ont été enregistrées avec succés"
End Sub

Dans l'userform Contact :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Option Explicit
Private Sub btnEnregistrer_Click()
Dim Contact As Untel
 Contact.Civilité = Me.tbxCivilité.Text
 Contact.Nom = Me.tbxNom.Text
 Contact.Prénom = Me.tbxPrénom.Text
 Contact.Adresse = Me.tbxAdresse.Text
 Contact.CP = Me.tbxCP.Text
 Contact.Ville = Me.tbxVille.Text
 Call Module1.Enregistre(Contact)
End Sub

Dans l'userform Personne :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Option Explicit
Private Sub btnEnregistrer_Click()
Dim Personne As Untel
 Personne.Civilité = Me.tbxCivilité.Text
 Personne.Nom = Me.tbxNom.Text
 Personne.Prénom = Me.tbxPrénom.Text
 Personne.Adresse = Me.tbxAdresse.Text
 Personne.CP = Me.tbxCP.Text
 Personne.Ville = Me.tbxVille.Text
 Call Module1.Enregistre(Personne)
End Sub

Le fichier : empiresailor.xlsm

[patricktoulon]

re
bonjour
transférer des donnée formulaire dans un sheets il y a beaucoup plus simple
EXEMPLE 1
tu a 5 textbox (nom,prenom,adresse,CP ,ville)
dans le tag de ces textbox (dans l'éditeur vbe) tu leur met la/les lettre(s) des colonnes correspondantes
et puis c'est tout le reste est très simple

Code :

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

1
2
3
4
5
6
7
8
Private Sub CommandButton1_Click()
Dim EntreePlus As Worksheet, ro&
  Set EntreePlus = ThisWorkbook.Worksheets("Feuil1")
ro = EntreePlus.Cells(Rows.Count, "B").End(xlUp).Offset(1).Row
For Each txt In Me.Controls
If txt.Tag <> "" Then EntreePlus.Cells(ro, txt.Tag) = txt
Next
End Sub

après encore plus simple tu envoie l'array d'un coup dans la première ligne dispo(xlup).offset(1)
EXEMPLE 2

Code :

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

1
2
3
4
5
6
7
Private Sub CommandButton2_Click()
Dim EntreePlus As Worksheet, ro&, newitem
  Set EntreePlus = ThisWorkbook.Worksheets("Feuil1")
ro = EntreePlus.Cells(Rows.Count, "B").End(xlUp).Offset(1).Row
newitem = Array(tbxNom, tbxPrénom, tbxAdresse, tbxCP, tbxVille)
EntreePlus.Cells(ro, "B").Resize(1, 5) = newitem
End Sub

un autre exemple avec un tableau structuré similaire a l'exemple 1 (même principe)sauf que dans le tag on mettrait les indexs de colonnes par rapport au tableau!!!!!!!! (pas du sheet)

Code :

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

1
2
3
4
5
6
7
8
Private Sub CommandButton3_Click()
With Sheets("Feuil1").Range("Tableau1").ListObject
 .ListRows.Add
For Each txt In Me.Controls
If txt.Tag <> "" Then .ListRows(.ListRows.Count).Range.Cells(Val(txt.Tag)) = txt
Next
End With
End Sub

j'ai parlé d'écriture dans le sheets mais avec ce procédé tu peut faire l'inverse
a savoir récupérer les données du sheets pour remplir le formulaire
le principe est tout simplement inverse
tu détermine ta ligne

et chaque textbox = .cells(lalignedeterminé,lettre du tag).value 'pour un range
ou pour un tableau structuré
textbox = range("tableau1").listobject .listrows(lalignedeterminé).range.cells(index dans le tag du textbox).value

c'est juste une question de conception au départ

[Arkham46]

Bonjour,

il y a beaucoup plus simple

La simplicité est tout relative et n'est pas une finalité.
Elle ne se mesure pas non plus en nombre de lignes de code.

Beaucoup plus simple ? Je ne comprends pas.

[patricktoulon]

bonjour arkham

beaucoup plus simple dans le sens ou:

1. pas besoins d'associer une variable quelconque a un textbox que se soit dans un module ou le UserForm
2. économie de mémoire
3. l'utilisation du tag permet justement de ne pas faire appel a la mémoire ce qui permet de ne pas perdre la donnée en cas de bug ailleurs dans vba qui réinitialiserait vba

et puis quoi de plus simple que de récupérer le tag du control pour déterminer la colonne
c'est la plus vielle recette et c'est pas moi qui l'ai inventé
c'est d'ailleurs un sujet qui a été demandé plusieurs fois et certains membre éminents seraient d'accords avec moi


un exemple pour te faire comprendre mon raisonnement

qu'elle est l'utilité de ca :

Code :

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

1
2
3
4
5
6
7
8
sub test
dim valeur as string ,valeur2 as string,lig as long
lig=sheets(1).range("A:A").end(xlup).offset(1).row
valeur=textbox1.value
valeur2=textbox2.value
sheets(1).cells(lig,1)=valeur
sheets(1).cells(lig,2)=valeur2
end sub

par rapport a ca par exemple

Code :

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

1
2
3
4
5
6
sub test
lig=sheets(1).range("A:A").end(xlup).offset(1).row
for i=1 to 5 
sheets(1).cells(lig,me.controls("textbox" & i).tag)=me.controls("textbox" & i).value
next
end sub

a mon sens seule la variable représentant l'index de la first ligne dispo doit être variable dans un formulaire d'enregistrement de données (personne)
et c'est pareil en lecture
et pour finir je conclurais que la simplicité de ce procédé ne réside pas que dans le nombre faible de lignes, mais dans son raisonnement tout court

[Arkham46]

La solution de Partice740 me convient mieux.
C'est structuré, on sait le rôle de chaque contrôle par son nom...

Gagner 2 lignes de codes en passant par un tag et un appel de contrôle par nom dans une variable n'est pas plus simple à mon goût.
Peut-être à très court terme à l'écriture, mais pour la maintenance bof bof..

[Pierre Fauconnier]

Salut.

Je me demande en quoi il est intéressant de remplir la même table avec des données provenant de formulaires différents (titre de la discussion)

Perso, je n'aime pas hardcoder les positions de colonne dans les tags des contrôles. Si, au hasard du développement de l'application, on ajoute ou permute des colonnes, on va devoir aller modifier les tags de tous les contrôles ou presque. De plus, travailler avec des Textbox1, textbox2 etc va vite devenir un véritable casse-tête pour savoir comment appairer les colonnes et les textbox. Il est toujours préférable de travailler avec des contrôles nommés de façon à en comprendre rapidement le contenu. Pour finir, l'exemple de Patrick part du principe que l'on travaille uniquement avec des textbox. Derrière donc cette apparente simplicité se cache une difficulté de lecture, de compréhension rapide, de maintenance et d'évolution. Si la plage de données qui reçoit les infos est déplacée, c'est également la galère. Je préfère de loin un code bien écrit, compréhensible et maintenable à du hardcoding et du code mal torché, surtout sous le prétexte d'une utilisation rationnelle de la mémoire

En 2019, Je n'arrive pas à comprendre pourquoi on propose encore des solutions avec plages, car on utilise évidemment les tables de données pour le stockage de ce genre de choses (voir mon tuto sur les tableaux structurés).

Au passage, comme Patrice740, je n'aime pas les variables publiques. Je les bannis systématiquement de mon code.


Perso, j'utilise une table de mappage pour réaliser l'opération. Elle est constituée d'une table de données contenant la paire de valeurs Nom de colonne / Contrôle. Une simple boucle sur un tableau issu de cette table de mappage permet de retrouver la concordance Colonne / Contrôle.



La table de données contiendra bien entendu les colonnes dont les noms sont renseignés dans la table de mappage.





On peut alors utiliser un userform dans lequel sont présents les contrôles renseignés dans cette table. En faisant abstraction du code du userform qui valide la saisie, un clic sur le bouton de validation du userform modifie simplement la valeur d'une propriété publique du userform qui sera utilisée par la suite:

Code :

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

1
2
3
4
5
6
7
8
Option Explicit
 
Public Result As String
 
Private Sub btnValidate_Click()
  Result = "Validate"
  Me.Hide
End Sub

Une procédure de module standard appelle le userform et traite les infos par la suite si validation. En cas d'ajout de colonnes/contrôles, cette procédure reste inchangée:

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
Sub Test()
  Dim Map
  Dim Counter As Long
  Dim NewRow As ListRow
 
  With usfContact
    .Show
    If .Result = "Validate" Then
      Map = Range("t_Map").Value
      Set NewRow = Range("t_Contacts").ListObject.ListRows.Add()
      For Counter = 1 To UBound(Map)
        NewRow.Range.Cells(NewRow.Parent.ListColumns(Map(Counter, 1)).Index).Value = .Controls(Map(Counter, 2)).Value
      Next
    End If
  End With
End Sub

On pourrait bien sûr variabiliser les noms des tables de données (t_Contacts et t_Map), dans le cas où on devrait pousser des données du même formulaire dans des tables différentes.

A cette solution, je préfère ajouter des propriétés publiques au userform pour pouvoir gérer plus facilement les données dont le type est différent de String, et utiliser la table de mappage avec les propriétés du userform, mais une chose à la fois.

[...]

1. [...]
2. l'utilisation du tag permet justement de ne pas faire appel a la mémoire ce qui permet de ne pas perdre la donnée en cas de bug ailleurs dans vba qui réinitialiserait vba

[...]

La non-utilisation des variables publiques, l'écriture de procédures/fonctions courtes à responsabilité unique et une bonne gestion des On Error permet d'éviter cela. Si ce problème survient, c'est uniquement parce que le code est mal conçu et mal écrit

[patricktoulon]

re
bonsoir pierre

une matrice dans un TS pour les correspondances(controls/colonnes) !!! ???
souhaitons ne pas avoir a faire la même chose avec d'autres tableaux
cela dit je préfère au variables car comme je l'ai dis vba peut planter ailleurs et tout perdre

perso j'ai utilisé le tag pour la correspondance pendant très longtemps et même encore aujourd'hui sur certains fichiers dont j'ai la flemme d'updater qui me servent moins souvent

sinon j'utilise l'array direct (exemple2)
et j'ai pas des noms de serie dans l'USF
je peux parfaitement modifier l'ordre,un des noms, ajouter, supprimer
un formulaire avec un tableau du genre conctact ;c'est quoi 10/15 données maxi


ce que j'ai essayé de dire tout a l'heure ;c'est de donner a une variable string ou autre la valeur d'un textbox (ou autre) et de donner a une cellule la valeur
la non je pige pas: on donne la valeur du textbox a une cellule par le textbox c'est tout
surtout si leur nom sont évocateurs comme il a été présenté ici

perso maintenant les variables me servent uniquement a déclarer des Object ou faire voyager des valeurs entre fonction ou module ou variables d'incrémentation dans une macro
et dans certaine occasion diminuer le code répétitif
après chacun fait sa soupe

[Pierre Fauconnier]

Je ne comprends pas bien ta remarque sur les matrices et les TS avec d'autres tableaux. Si tu as x tableaux associés à x formulaires, soit tu as x tables de mappage, soit tu as une seule table avec une colonne supplémentaire. En quoi ça gêne? Dans ta solution avec arrays, il te faudra bien x arrays hardcodés. Tu parles d'une solution

Il te suffit de nommer proprement tes tables et tu t'y retrouves sans problèmes. Cette approche permet la systématisation du processus, et donc l'utilisation de code générique basé sur du paramétrage. Comme je l'ai dit, la procédure Test que j'ai proposée ne doit en rien être modifiée lors de l'ajout, la suppression, la permutation ou le renommage des colonnes ou des contrôles. Dans le userform, il ne faudra pas modifier les contrôles déjà en place (ni leurs tags, ni leurs noms,...). Seules les tables de mappage doivent être modifiées, ainsi bien sûr que le code du userform afférant aux nouveaux contrôles qui seraient ajoutés. Pour moi, le fait qu'il y ait peu ou beaucoup de données à modifier n'entre pas en ligne de compte. Ce qui est important, c'est la systématisation de l'approche et du codage. C'est le super pied, surtout lorsque, justement, tu as plusieurs paires table/userform à gérer

Cela dit, désolé, mais pour moi, coder des textbox & i et des lettres de colonnes dans des tag de contrôles, ce n'est pas propre du tout. L'utilisation de tags non plus, et les arrays de mappage hardcodés non plus, pour les raisons que j'ai invoquées:

• Listbox1, listbox2 sont des termes incompréhensibles de prime abord (on ne sait pas à quoi ils se réfèrent;
• Si on déplace, ajoute, permute des colonnes, il faut mettre les mains dans le cambouis et modifier inutilement du code (ce qui implique risques d'erreurs et tests supplémentaires);
• Hardcoding, ce qui n'est vraiment pas une bonne manière de coder;
• La non-utiliation des tableaux structurés (qui facilitent l'appairage colonne/contrôle) est pour moi un non-sens en 2019.

Ceci dit, tu proposes effectivement l'exemple 2 avec un array qui évite les noms suffixés des contrôles, mais je préfère une table de mappage que le hardcoding. Cela dit, si tu préfères la solution de l'array, pourquoi proposes-tu l'histoire des textbox & i dans ton message suivant? En programmation, la constance dans une solution à laquelle on croit est préférable à des solutions qui varient tout le temps.


Comme dit précédemment, la perte des valeurs lors d'un bug représente un faux problème lorsque l'on sait gérer correctement les On Error....


Après, comme tu le dis, chacun sa soupe, mais je préfère un million de fois la mienne à la tienne

[clementmarcotte]

Bonjour,

Ouais,

On a quelqu'un qui pose visiblement sa première question sur le forum, ou à peu près; et vous lui balancez un débat de vieux spécialistes. À ce que je pense et ce que je sache, son besoin c'est d'une solution qui fonctionne. Sans nier la nécessité de débattre à certains moments, il faudrait peut-être ajouter un lien entre le sujet et un sous-forum consacré au(x) débat(s) qui émergerai(ent) à la suite d'une réponse à une question

Parce que là, à mon avis, et ce n'est pas la première fois, vos débats très (peut-être même trop) "pointus" ne sont pas vraiment à la portée des gens qui posent leur question sur un problème terre-à-terre.

Parce que, entre comprendre à fond vos arguments et apprendre un nouveau langage...

[Patrice740]

... 3. l'utilisation du tag permet justement de ne pas faire appel a la mémoire ...

D'après-toi où donc est stockée l'information contenue dans le tag ?
Si on peut se passer de la mémoire on va pouvoir faire des miracles avec un ZX81 !!!

...ce qui permet de ne pas perdre la donnée en cas de bug ailleurs dans vba qui réinitialiserait vba

Et si VBA plante au point qu'il faut le réinitialiser, comment comptes-tu accéder au tag ????

[patricktoulon]

re
Bonjour patrice
après un plantage d'une macro quelconque ,tu a toujours accès au controls et donc ces propriétés par contre tout ce qui était en mémoire dans des variables c'est mort sauf jouer avec on error et occulter l'erreur ce qui rends la macro ou l'évènement inutilisable sur le coup

je peux en parler c'est un soucis que je ne n'est pas résolu avec une variable uiribbon qui est vidée après une erreur dans une autre macro
et je n'est rien trouvé pour palier a ca

[Pierre Fauconnier]

[...]tout ce qui était en mémoire dans des variables c'est mort

On s'en fout puisqu'il faudra de toute façon relancer toute la procédure, on repassera donc forcément sur les instructions qui affectent des valeurs aux variables. De plus, en programmant des procédures/fonctions recevant des valeurs en paramètres (ce que préconise Patrice), ce problème n'existe tout simplement pas. S'il existe, c'est que le code est mal architecturé et est bourré de variables publiques, ce qui est à proscrire, comme nous le disons Patrice et moi.

Tes remarques sur l'utilisation de la mémoire sont incohérentes puisque tu dis toi-même dans un message qu'il s'agit au plus de 10 ou 15 données maxi. Avant que l'on doive se préoccuper de la mémoire d'un ordinateur moderne avec ce volume de données, il aura coulé de l'eau sous les ponts...

[...]
un formulaire avec un tableau du genre conctact ;c'est quoi 10/15 données maxi[...]

[...]sauf jouer avec on error et occulter l'erreur ce qui rends la macro ou l'évènement inutilisable sur le coup

"Jouer", comme tu dis, avec On Error, ce n'est certainement pas occulter l'erreur (ça, c'est lorsque l'on ne sait pas programmer correctement la gestion d'erreurs). C'est, lorsque c'est bien programmé, gérer l'erreur, ce qui n'est pas du tout la même chose.

[patricktoulon]

re
ne te méprends pas dans mes dires pierre c'est pas la quantité qui me préoccupe (avec les pcs actuels c'est plus un problème) c'est la perte de donnée

[Pierre Fauconnier]

[...]c'est la perte de donnée

C'est un faux problème. Si le code est arrêté, toutes les données en mémoire sont perdues, point à la ligne. Dans tous les exemples que tu as donnés, tu utilises des variables, qui seront elles aussi perdues en cas d'arrêt forcé du code. Il faudra de toute manière tout relancer.

Ton argument de la perte des valeurs ne tient donc pas la route. Il n'y a pas lieu de parler de problème de mémoire, quel qu'il soit, dans les cas de figure exposés ici. A part perdre le demandeur dans des considérations inutiles, ça ne sert à rien de parler d'un problème qui n'existe pas!

Et qu'on ne se méprenne pas sur mes propos, je ne dis qu'il n'y a pas perte de variables, je dis que ça n'a aucune importance, qui plus est lorsque le code est pro. C'est pourquoi j'insiste tant, malgré certaines critiques, sur un code propre et pro, même pour un "débutant".

[...]
je peux en parler c'est un soucis que je ne n'est pas résolu avec une variable uiribbon qui est vidée après une erreur dans une autre macro
et je n'est rien trouvé pour palier a ca

La seule façon de pallier ce problème, c'est de programmer correctement la gestion d'erreurs, et donc les On Error, pour éviter de devoir arrêter le code et donc de perdre la variable du ruban. il n'y a pas d'autres façons, puisque le ruban est chargé lors de l'ouverture du fichier sans que tu aies la main dessus.

[...]

C'est selon moi une ineptie sans nom de soutenir que parce qu'on est débutant, on doit recevoir des réponses qui apprennent des mauvaises façons de coder

[clementmarcotte]

C'est selon moi une ineptie sans nom de soutenir que parce qu'on est débutant, on doit recevoir des réponses qui apprennent des mauvaises façons de coder

Tu peux professer ce que tu veux mais mon premier professeur de programmation a déjà dit que la première chose à faire c'est un programme "qui marche". Après on peut optimiser et améliorer.

C'est aussi une ineptie de croire que le demandeur ne reverra pas son code dans quelques mois, quand il aura plus d'expérience. Et de toutes façons, tu n'as aucun argument sur le fait que tu imposes un débat d'experts à une personne qui n'y comprend probablement rien.


Et sur le fond de la chose, je répète que le débat est peut-être nécessaire, mais; toujours sur fond de la chose, il peut être poursuivi sur un autre espace, avec des références à cette page.

Et au moment où j'écris ces lignes, cela fait pratiquement 36 heures que la question a été posée et le demandeur n'a rien ajouté à ce sujet. Ou bien, il a choisi une solution, ou bien il a fui. Et depuis ma réflexion sur les débats hermétiques, les seuls qui ont écrit quelque chose dans ce sujet, sont ceux qui mènent un débat hermétique.

[clementmarcotte]

Bonjour,

Salut.


Au passage, comme Patrice740, je n'aime pas les variables publiques. Je les bannis systématiquement de mon code.

Ça, ça marche quand les paramètres sont passés par référence (ByRef); le paramètre par défaut de VBA. Quand les paramètres sont passés par valeur (ByVal), la valeur par défaut dans d'autres langages, c'est beaucoup moins vrai. Sinon, dès que la valeur d'une variable passée en paramètre est modifiée, on se retrouve avec deux valeurs pour la même variable. La seule solution, à part ajouter un paramètre "vide" qui va retourner la valeur modifiée à la procédure appelante, demeure les variables publique. Ou bien, on accepte la perte de productivité en ajoutant systématiquement ByRef. Pour quelques lignes, cela demeure vivable, mais cela peut se révéler coûteux à la longue. Ou bien, il faut jouer avec des fichiers externes temporaires ou le registre. Et que cela te plaise ou non, je le sais par expérience avec un langage que tu ne veux pas voir.

[Patrice740]

Bonjour,

...Ou bien, on accepte la perte de productivité en ajoutant systématiquement ByRef. Pour quelques lignes, cela demeure vivable, mais cela peut se révéler coûteux à la longue.

Celle là il fallait l'oser !!!
A comparer avec la perte de productivité à cause d'un code mal écrit par fainéantise !!!

[clementmarcotte]

Bonjour,

Celle là il fallait l'oser !!!
A comparer avec la perte de productivité à cause d'un code mal écrit par fainéantise !!!

Avant de dire des âneries, prend n'importe quel de tes programmes VBA et utilise systématiquement ByReh dans tes macros. Tu va voir le bordel de passer de un à l'autre samns variables publiques. Avant d'insulter les autres, vérifie joualvert.

J'ai assez expérimenté la différence entre ByVal et Byref pour voir la différence jouyalvert

Quand tu auras essayé et vérifié la différence, tu pourras parler, et pas avant.

Et puis, dans VB.net, tu dois déclarer des variables et des procédures publiques ou Friend, pour pour les appeler d'une autre classe. Mais comme tu ne veux juste pontifier et pas vérifier, tu peur continuer tes commérages.