Discussion :

[symbiioz]

Bonjour,

Pour enregistrer des données inscrites dans un useform, je viens les copiers sur une feuille.
Ici, j'ai 6 textbox, 3 pour une date de début, 3 pour une date de fin, et chaque groupe de 3 et composé du jour, mois, année.

Je viens donc récupérer les 3 données que je concatène pour faire la date dans une cellule au format 16/09/2019.

Pour la date de fin aucun soucis, mais pour la date de début, il inverse la textbox du jour et du mois et au lieu de me retrouver avec un 01/09/2019 je me retrouve avec un 09/01/2019 ! En faisant la différence de jour, il le prend réellement comme un jour de janvier.. je suis obligé dans le code d'inverser la texbox du jour et du mois pour avoir le bon résultat.. Illogique.

Le code :

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 UserForm_QueryClose(Cancel As Integer, CloseMode As Integer)
 
Dim accueil As Worksheet
Set accueil = Feuil7
 
Dim a, b As Date
 
    'Enregistrer les valeurs du formulaire dans la page d'accueil
accueil.Cells(6, 2) = Repertoire.Value
accueil.Cells(5, 2) = Lecteur.Value
 
a = txbJourDébut & "/" & txbMoisDébut & "/" & txbAnDébut
b = txbJourFin & "/" & txbMoisFin & "/" & txbAnFin
'a = Format(a, "dd/mm/yy")
 
accueil.Cells(8, 2) = a
accueil.Cells(9, 2) = b
accueil.Cells(10, 2) = WorksheetFunction.NetworkDays_Intl(a, b, 1, [tableau2])
 
End Sub

Le useform :


Pour la date de début, le jour est bien txbJourDébut, le mois txbMoisDébut, l'année txbAnDébut
La date de fin, jour txbJourFin, mois txbMoisFin, année txbAnFin

Si besoin je partagerai un fichier light, car celui-ci est lourd et avec des données sensibles.

Merci,
Symbiioz

[Menhir]

Pour la date de fin aucun soucis, mais pour la date de début, il inverse la textbox du jour et du mois et au lieu de me retrouver avec un 01/09/2019

C'est juste une coïncidence mais le problème est le même pour les deux date et se produira pour toute date dont le nombre du jour est égale ou inférieur à 12.

Modifie ton code ainsi :

Code :

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

a = DateSerial(txbAnDébut, txbMoisDébut, txbJourDébut)

Même chose pour "b", bien sûr.

[boudoula]

Bonjour

je constate que dans ton code seul la variable b et déclarée en date, je pense que si tu déclares aussi la a en date tout devrait mieux se passer

Code :

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

Dim a as Date, b As Date 'au lieu de Dim a, b As Date

[Menhir]

je pense que si tu déclares aussi la a en date tout devrait mieux se passer

On parie ?

Effectivement, tu as raison de dire que cette erreur est à corriger.
Mais ce n'est pas ça qui guérira VBA de son indéfectible envie d'inverser jour et mois dans une date dès qu'il le peut.

Quand on manipule des dates en VBA, il ne faut JAMAIS passer par des chaines de caractère mais être rigoureux et manipuler les date avec des fonctions de date.

[Docmarti]

Quand on ecrit une date dans une cellule, on doit utiliser .FormulaLocal

Code :

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

1
2
3
4
5
accueil.Cells(6, 2).FormulaLocal = Repertoire.Value
accueil.Cells(5, 2).FormulaLocal = Lecteur.Value
 
accueil.Cells(8, 2).FormulaLocal = a
accueil.Cells(9, 2).FormulaLocal = b

[Menhir]

Quand on ecrit une date dans une cellule, on doit utiliser .FormulaLocal

Uniquement si on l'inscrit sous forme de chaine de caractère (ce que, personnellement, je déconseille).

Je conseille plutôt de l'écrire en tant que valeur (avec une variable de type Data ou plus simplement Double) et mettre la cellule au format de date souhaité (ce qui peut éventuellement se faire en VBA avec la propriété NumberFormat).

[Docmarti]

Uniquement si on l'inscrit sous forme de chaine de caractère (ce que, personnellement, je déconseille).

Je conseille plutôt de l'écrire en tant que valeur (avec une variable de type Data ou plus simplement Double) et mettre la cellule au format de date souhaité (ce qui peut éventuellement se faire en VBA avec la propriété NumberFormat).

Je suis entierement d'accord pour dire que l'ecriture d'une date dans une cellule est tres complexe si on utilise VALUE.

Par contre je trouve que ca devient d'une grande simplicite si j'utilise FORMULALOCAL car le probleme d'inversion Jour/Mois n'existe plus.

[Pierre Fauconnier]

Je suis entierement d'accord pour dire que l'ecriture d'une date dans une cellule est tres complexe si on utilise VALUE.[...]

Ecrire une date dans une cellule n'est absolument pas complexe et ne nécessite pas .formulalocal que je refuse d'utiliser dans mon code.

Si problème, il se situe en amont, dans la transformation d'une chaine de caractères en date. Mais ce problème, qui se résoud avec une fonction générique, n'a rien à voir avec l'injection d'une date dans Excel qui ne pose aucun problème

[MarcelG]

Bonsoir à tous,

Je me permets d'intervenir.

Les formulaires et les dates... Vaste sujet.

Je rejoins en quelque sorte Menhir sur le principe.

Pour ma part, en effet, j'ai pris comme habitude de traiter les numéros de série des dates plutôt que les dates elles-mêmes.

Pour ce faire, je prends la précaution de supprimer le format de la cellule où sera injectée cette date.

L'avantage de traiter le numéro de série en amont est que celui-ci peut-être défini en fonction d'un Textbox ou plusieurs.
Ceci en sachant qu'un Textbox ne renvoie, à priori, que du texte

Je viens de tester.

Voici mon code quant à 2 boutons de commande.
Comme vous pourrez le voir, 3 Textbox concernent les 3 parties d'une date, 1 Textbox concerne la date en entier (séparateur "/")

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
Option Explicit
 
Private Sub Btn_en_entier_Click()
 
Dim s As Variant
 
With Range("A1")
        .ClearFormats
        s = Split(Me.Txt_entier, "/")
        .Value = DateSerial(s(2), s(1), s(0))
        .NumberFormat = "dd mmm yyyy"
End With
Unload Me
End Sub
 
Private Sub Btn_par_petits_bouts_Click()
With Range("A1")
        .ClearFormats
        .Value = DateSerial(Txt_année, Txt_mois, Txt_jour)
        .NumberFormat = "dd mmm yyyy"
End With
Unload Me
End Sub

J'ajouterai que je considère ce même processus pour une recherche.
Mieux vaut, selon Marcel, rechercher un numéro de série plutôt qu'une date.

Donc pour une recherche
- Supprimer le format de la zone de recherche
- Rechercher le numéro de série
- Rétablir le Format

Cette règle, à laquelle je ne me suis pas toujours fié, shunte par nature les éternels débats quant aux arguments de la méthode Find (Lookat, Lookin)

Merci pour vos retours.

D'ici là, bonne soirée à vous, bonne soirée au Forum.

[Pierre Fauconnier]

Mon 2ième grain de sel...

[...]
Les formulaires et les dates... Vaste sujet.[...]

Vaste sujet parce que l'approche n'est pas systématique...


Un textbox ne renvoie pas a priori du texte. Un textbox renvoie du texte. Point barre.

Si des "box" pouvaient renvoyer des long ou des double ou des bidule, on les auraient appelés longbox, doublebox ou bidulebox.

A partir de là, si on attend la saisie d'une date dans un textbox, on a comme seul choix de transformer le texte en date ( as date) selon le format de saisie attendu. Après, on utilise la date pour ce pour quoi on l'utilise. Le format d'une cellule n'a strictement rien à voir ici.

Transformer du texte (au format attendu) en date requiert juste une fonction que l'on se doit, si on veut être pro, d'avoir dans un module Tools.

Les discussions, interminables, sur les dates sur les forums VBA viennent du fait que les "programmeurs" ne respectent pas cette manière de procéder.

Mon ton péremptoire vient de mon exaspération due à ce que l'on rend complexe une chose qui ne l'est pas du tout:

• Saisir une date dans un textbox;
• Vérifier si la saisie est conforme au résultat attendu;
• Si oui, transformer saisie en date (grâce à une fonction générique);
• utiliser la valeur as date par la suite.

Il n'y a rien de "très complexe" ou d'absurde. Il faut juste être systématique dans son approche.

[MarcelG]

(Je suis à la bourre, pas grave...)

Tu l'auras peut-être compris, Pierre, mon "à priori" était ironique.
Trop souvent, l'on voit écrites d'autres considérations alors que s'interroger sur la nature même d'une Textbox est une base essentielle.

Maintenant, chacun son avis bien entendu. Et je ne peux qu'admettre ce que tu avances.

A mon niveau, considérer les numéros de série peut éviter, au développeur lambda, dont je suis, bien des soucis.
Certes, cela peut ne paraître pas très "pro".

Et, à mon humble avis, c'est encore plus vrai pour la recherche de date.
Mieux vaut rechercher un numéro de série qu'une date.

A bientôt.

[Menhir]

J'ai toujours fait en sorte d'éviter les UserForm (c'est un choix qui se discute mais jusqu'à présent, je m'en porte très bien) donc, à fortiori, les TextBox.

Mais lorsque je dois récupérer des dates d'un fichier texte exporté d'une autre application, la seule méthode qui pour moi est fiable (aux erreurs de données source près), c'est, comme MarcelG, la combinaison Split + DateSerial.

Dans le cas présent (ne pas l'oublier, quand même ), le Split n'est pas nécessaire puisque l'utilisateur a séparé jour, mois et année dans trois champs différents.

[MarcelG]

Bonjour Menhir, Bonjour le Forum,

Comme tu as pu le voir, j'ai élargi la discussion pour envisager les 2 cas (3 éléments séparés, date entière).

Par ailleurs, j'aurais souhaité avoir votre sentiment quant à la recherche que j'évoque dans la 2ème partie de mon post.

Merci et à bientôt.

[Menhir]

J'ajouterai que je considère ce même processus pour une recherche.
Mieux vaut, selon Marcel, rechercher un numéro de série plutôt qu'une date.

Je ne pense pas avoir jamais utilisé une date comme clé de recherche pure.

Il m'arrive par contre d'en utiliser dans des fonctions "apparentées" comme SOMME.SI.ENS().
Dans ce cas, je mets toujours deux conditions pour borner la date et j'utilise la fonction DATE() ou une cellule date pour spécifier le critère.

Donc pour une recherche
- Supprimer le format de la zone de recherche
- Rechercher le numéro de série
- Rétablir le Format

Je n'ai jamais fait de vérification rigoureuse sur ce que je vais affirmer mais, pour moi, le format de cellule est purement cosmétique et n'influe en rien sur le contenu de la cellule.
Donc Supprimer/Rétablir ce format pour faire une recherche, pour moi ça n'a pas de raison : rien n'empêche de rechercher sur un numéro de série de date quand la cellule est au format date.

Techniquement, le format ce cellule n'influe pas sur la propriété Value d'une Range (mais il influe sur la propriété Text).

[MarcelG]

Je viens de tester, Menhir

Si en colonne A, sont reportées les valeurs



Si un bouton de commande a pour code affecté

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 Btn_Recherche_Click()
 
Dim s As Variant
Dim t As Range
Dim lavaldate As Long
 
s = Split(Me.Txt_entier, "/")
lavaldate = DateSerial(s(2), s(1), s(0))
 
With Range("A15:A30")
        '.ClearFormats
        Set t = .Find(what:=lavaldate, LookIn:=xlValues)
        MsgBox t.Address
        Set t = Nothing
        '.NumberFormat = "dd/mm/yyyy"
End With
 
Unload Me
 
End Sub

Alors message d'erreur sur la ligne "adresse"car t =Nothing.

Si les formats sont supprimés puis restaurés, alors t est trouvé.

Et cela m'étonne car, comme le spécifie Didier dans son tutoriel

il faut savoir qu'Excel stocke :
•Les dates sous forme de nombres de jours entiers (depuis l'" origine" ).

et toi-même, les dates sont considérées comme des nombres.

Quelque chose m'échappe.

Je reviens à l'instant car j'effectue quelques recherches à ce sujet.

L'ami Theze, que je salue au passage, fait allusion au format dans cette discussion
Sur d'autres forum, le format semble être mis en question pour ce genre de problématique.

Si je m'inspire du code de Theze

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
Private Sub Btn_Recherche_Click()
 
Dim t As Range
Dim lavaldate As Long
 
lavaldate = DateValue(Me.Txt_entier)
Debug.Print lavaldate
 
With Range("A15:A30")
        .ClearFormats
        Set t = .Find(what:=lavaldate, LookIn:=xlValues)
        MsgBox t.Address
        Set t = Nothing
        .NumberFormat = "dd/mm/yyyy"
End With
 
Unload Me
 
End Sub

Alors je fais la même constatation.

[Menhir]

Effectivement, j'ai fait des tests, le format de cellule a une influence sur le Find.
Ce qui signifie que le Find (comme la commande Rechercher), cherche dans ce qui est affiché et non dans les valeurs de cellules.
Ca me conforte dans l'idée que les dates c'est de la nitroglycérine et de ne jamais utiliser de recherche sur les dates.

Petit détail (histoire de pinailler) : les dates (au sens large) ne sont pas conservées sous forme de nombre entier de jours mais sous forme de nombre décimal.

[MarcelG]

Merci, Menhir.

Oui pour le stockage, j'avais dans l'esprit une date jour mois an.
La parte décimale correspond aux heures, minutes, secondes.

Je viens de modifier mon dernier post en citant notre ami Theze.
Nous avons fait tous les 3 la même constatation.

Et pourtant, cela m'intrigue.

PS: J'utilise Excel 2016

[Pierre Fauconnier]

[...]
Ce qui signifie que le Find (comme la commande Rechercher), cherche dans ce qui est affiché et non dans les valeurs de cellules.[...]

Je tempèrerais ce propos suite au test que je viens de faire. Avec la date 15/04/2019 au format jjjj, la recherche dans Excel sur "lundi" s'arrête bien sur la cellule, mais pas FIND. Avec FIND, il faut rechercher "monday"...

Je pense que ce n'est pas la recherche des dates qui est de la nitroglycérine, c'est FIND qui ne réagit pas de la même manière en Excel et en VBA...

[Thumb down]

Bonjour,
symbiioz a été admis aux urgences pour une entorse au synapses !

[Menhir]

Je pense que ce n'est pas la recherche des dates qui est de la nitroglycérine, c'est FIND qui ne réagit pas de la même manière en Excel et en VBA...

L'un n'empêche pas l'autre.