Vba Recherche de la date du jour dans une colonne qui les contient toutes

Bonjour.
Pas de problème chez moi, si activecell est en colonne C et si la date ne
résulte pas d'une formule.
Cordialement.
Daniel
"Jac" <Jsansp@mfra.net> a écrit dans le message de news:
mn.53937d88d1df8fdc.89607@mfra.net...

Bonjour à tous,

je cherche à me positionner dans un tableau qui contient toutes les dates
de l'année sur le jour actuel. Je reçois systématiquement une erreur
d'exécution 13 / Incompatibilité de type avec cette syntaxe :

[C:C].Find(What:Úte, After:¬tiveCell, LookIn:=xlValues).Activate

J'ai essayé de formater la date pour qu'elle soit identique au formatage
de la colonne C. Rien à faire. Si je mets Date en variable, Excel
l'affiche au même format la date qui existe dans le tableau.

Et maintenant, je manque d'imagination pour résoudre le problème...

Merci d'avance à qui pourrait me mettre sur la voie.

Jac

Bonjour,


http://boisgontierjacques.free.fr/fichiers/FindDates.xls

JB
http://boisgontierjacques.free.fr


On 10 août, 15:15, Jac <Jsa...@mfra.net> wrote:

Bonjour à tous,

je cherche à me positionner dans un tableau qui contient toutes les
dates de l'année sur le jour actuel. Je reçois systématiquement une
erreur d'exécution 13 / Incompatibilité de type avec cette syntaxe :

[C:C].Find(What:=Date, After:=ActiveCell, LookIn:=xlValues).Activat e

J'ai essayé de formater la date pour qu'elle soit identique au
formatage de la colonne C. Rien à faire. Si je mets Date en variable,
Excel l'affiche au même format la date qui existe dans le tableau.

Et maintenant, je manque d'imagination pour résoudre le problème...

Merci d'avance à qui pourrait me mettre sur la voie.

Jac

Une idée parmi d'autres (plage de recherche à adapter):

Sub essai()
Dim pos
pos = Application.Match(CLng(Date), Range("C3:C368").Value2, 0)
Application.Goto Range("C" & pos)
End Sub

FS
---
Frédéric Sigonneau
http://frederic.sigonneau.free.fr

Jac a écrit :

Bonjour à tous,

je cherche à me positionner dans un tableau qui contient toutes les
dates de l'année sur le jour actuel. Je reçois systématiquement une
erreur d'exécution 13 / Incompatibilité de type avec cette syntaxe :

[C:C].Find(What:Úte, After:¬tiveCell, LookIn:=xlValues).Activate

J'ai essayé de formater la date pour qu'elle soit identique au formatage
de la colonne C. Rien à faire. Si je mets Date en variable, Excel
l'affiche au même format la date qui existe dans le tableau.

Et maintenant, je manque d'imagination pour résoudre le problème...

Merci d'avance à qui pourrait me mettre sur la voie.

Jac

Quand tu recherches une date, ce n'est jamais facile...
si tu fais pas attention, les dates vont te donner des datttes !!!
;-)

Exemple : Les 2 méthodes proposées par JB... fonctiionne mais
tel que présentées, a condtion que dans les 2 cas le format
retenu dans la boîte de dialogue du menu / format / cellule / nombre ...
soit celui défini avec UN ASTÉRIX devant le format Que ce soit pour
la colonne du format court des dates ou du format long des dates dans
les cellules. Si dans ces cellules, il y avait un format personnalisé
utilisant
le même format que le format court ou long, les 2 procédures font couic (
adjectif fréquemment utilisé par AV). Un usager qui emploie ce type de
procédures....comment fait-il pour savoir de quelle nature est son probleme
lorsque les procédures plantes ? À titre de suggestion, JB devrait ajouter
à son classeur, une note explicative... De quoi je me mèle ? ;-))

Pour ce qui est de la méthode proposée par Frédéric Sigonneau, bien que
ce ne soit pas une erreur en soi, je me demande de la pertinence d'utiliser
la propriété Value2 de l'objet Range dans cette formule. Et dans le cas où
la date affichée dans la cellule provient d'une format de
ce type : =TEXTE("11/01/06";"JJ/MM/AA"), la méthode proposée ferait
aussi couic...;-)))

Conclusion : Faire une recherche d'une date, en se basant sur seulement
l'apparence de ce qu'il y a dans la plage de cellules n'est pas évident. Ce
n'est pas parce que dans une situation ça marche que la méthode proposée
est une panacée acceptable à toutes les situations.

Si tu veux lire un peu sur la méthode Find et Date, il y a quelqu'un qui a
écrit
un papier pas mal intéressant sur le sujet là :
http://xlwiki.free.fr/wiki/wakka.php?wiki=RechercheDate

Oups ! J'allais oublié de mentionner que l'auteur de ces lignes et le même
que l'auteur du papier ! Aurait-il un parti pris ? ;-))


"Jac" <Jsansp@mfra.net> a écrit dans le message de news:
mn.53937d88d1df8fdc.89607@mfra.net...
Bonjour à tous,

je cherche à me positionner dans un tableau qui contient toutes les
dates de l'année sur le jour actuel. Je reçois systématiquement une
erreur d'exécution 13 / Incompatibilité de type avec cette syntaxe :

[C:C].Find(What:Úte, After:¬tiveCell, LookIn:=xlValues).Activate

J'ai essayé de formater la date pour qu'elle soit identique au
formatage de la colonne C. Rien à faire. Si je mets Date en variable,
Excel l'affiche au même format la date qui existe dans le tableau.

Et maintenant, je manque d'imagination pour résoudre le problème...

Merci d'avance à qui pourrait me mettre sur la voie.

Jac

Merci à tous, pour vos bons conseils.

Je ne pensais pas que chercher une date pouvait poser autant de
problème(s).

Je ne pensais pas non plus que vous, les gentils contributeurs, seriez
là, le dimanche 10 août, après le déssert... devant un écran au lieu de
faire la sieste.
Je vous imaginais plutôt à surveiller enfants ou petits enfants en bord
de mer, autour d'un lac de montagne ou battant la campagne (et pas la
compagne)...
Mais c'est sans doute déjà terminé ou ça va arriver...

Jac

> Pour ce qui est de la méthode proposée par Frédéric Sigonneau, bien que

> ce ne soit pas une erreur en soi,

Je suis très sensible à ta bénédiction, maître Denis !

> Et dans le cas où
> la date affichée dans la cellule provient d'une format de
> ce type : =TEXTE("11/01/06";"JJ/MM/AA"), la méthode proposée ferait
> aussi couic...;-)))

Ah, ben, évidemment ! Si on dit qu'on cherche une date mais qu'en réalité il
faut comprendre qu'on cherche du texte, c'est sûr que ça va pas marcher !

> je me demande de la pertinence d'utiliser
> la propriété Value2 de l'objet Range dans cette formule

Bonne demande en effet. La propriété Value2 est (injustement) méconnue, même
s'il est vrai qu'elle ne sert pas à grand-chose en dehors de ce cas de figure.
Sans compter qu'il faut penser que les objets ont des propriétés, ce que
malheureusement la grande tolérance du langage VBA aux approximations
syntaxiques de ses utilisateurs a tendance à leur faire oublier.
Mais, bref, revenons à Value2. La propriété Value2 d'un cellule qui contient une
date a la particularité très appréciable de renvoyer cette date sous forme de
son numéro de série, c'est-à-dire un entier long.
Il est donc
-très facile de faire une recherche avec Match (Equiv) en fournissant la date à
chercher sous forme d'un Long (par ex Clng(Date))
-très sûr d'utiliser cette méthode qui se moque royalement de la _forme_ sous
laquelle est affichée la date (à condition bien sûr qu'on ne cherche pas une
date parmi des carottes) !
En VBA, c'est, de mon point de vue, la méthode la plus simple et la plus fiable.
Mais ce n'est que mon point de vue :)

FS
---
Frédéric Sigonneau
http://frederic.sigonneau.free.fr

michdenis a écrit :

Quand tu recherches une date, ce n'est jamais facile...
si tu fais pas attention, les dates vont te donner des datttes !!!
;-)

Exemple : Les 2 méthodes proposées par JB... fonctiionne mais
tel que présentées, a condtion que dans les 2 cas le format
retenu dans la boîte de dialogue du menu / format / cellule / nombre ...
soit celui défini avec UN ASTÉRIX devant le format Que ce soit pour
la colonne du format court des dates ou du format long des dates dans
les cellules. Si dans ces cellules, il y avait un format personnalisé
utilisant
le même format que le format court ou long, les 2 procédures font couic (
adjectif fréquemment utilisé par AV). Un usager qui emploie ce type de
procédures....comment fait-il pour savoir de quelle nature est son probleme
lorsque les procédures plantes ? À titre de suggestion, JB devrait ajouter
à son classeur, une note explicative... De quoi je me mèle ? ;-))

Pour ce qui est de la méthode proposée par Frédéric Sigonneau, bien que
ce ne soit pas une erreur en soi, je me demande de la pertinence d'utiliser
la propriété Value2 de l'objet Range dans cette formule. Et dans le cas où
la date affichée dans la cellule provient d'une format de
ce type : =TEXTE("11/01/06";"JJ/MM/AA"), la méthode proposée ferait
aussi couic...;-)))

Conclusion : Faire une recherche d'une date, en se basant sur seulement
l'apparence de ce qu'il y a dans la plage de cellules n'est pas évident. Ce
n'est pas parce que dans une situation ça marche que la méthode proposée
est une panacée acceptable à toutes les situations.

Si tu veux lire un peu sur la méthode Find et Date, il y a quelqu'un qui a
écrit
un papier pas mal intéressant sur le sujet là :
http://xlwiki.free.fr/wiki/wakka.php?wiki=RechercheDate

Oups ! J'allais oublié de mentionner que l'auteur de ces lignes et le même
que l'auteur du papier ! Aurait-il un parti pris ? ;-))


"Jac" <Jsansp@mfra.net> a écrit dans le message de news:
mn.53937d88d1df8fdc.89607@mfra.net...
Bonjour à tous,

je cherche à me positionner dans un tableau qui contient toutes les
dates de l'année sur le jour actuel. Je reçois systématiquement une
erreur d'exécution 13 / Incompatibilité de type avec cette syntaxe :

[C:C].Find(What:Úte, After:¬tiveCell, LookIn:=xlValues).Activate

J'ai essayé de formater la date pour qu'elle soit identique au
formatage de la colonne C. Rien à faire. Si je mets Date en variable,
Excel l'affiche au même format la date qui existe dans le tableau.

Et maintenant, je manque d'imagination pour résoudre le problème...

Merci d'avance à qui pourrait me mettre sur la voie.

Jac

| Je suis très sensible à ta bénédiction, maître Denis !

**** J'espère...! ;-)))

Et dans le cas où

> la date affichée dans la cellule provient d'une format de
> ce type : =TEXTE("11/01/06";"JJ/MM/AA"), la méthode proposée ferait
> aussi couic...;-)))

| Ah, ben, évidemment ! Si on dit qu'on cherche une date mais qu'en réalité
il
| faut comprendre qu'on cherche du texte, c'est sûr que ça va pas marcher

**** L'objectif était de faire comprendre que de se fier sur ce qui est
affiché
dans la plage de cellules n'est pas suffisant pour qu'une procédure
donnée
fonctionne... cela s'inscrivait à la suite du commentaire fait sur la
proprosition de JB !

> je me demande de la pertinence d'utiliser
> la propriété Value2 de l'objet Range dans cette formule

Bonne demande en effet. La propriété Value2 est (injustement) méconnue, même
s'il est vrai qu'elle ne sert pas à grand-chose en dehors de ce cas de
figure.

| Sans compter qu'il faut penser que les objets ont des propriétés, ce que
| malheureusement la grande tolérance du langage VBA aux approximations
| syntaxiques de ses utilisateurs a tendance à leur faire oublier.

**** Tu as parfaitement raison sur ce point sauf que pour un novice il y a
des choses difficiles à comprendre. Exemple :

En supposant que dans la plage A1:A25, on a des dates reconnues par excel,
lorsque l'on omet de nommer explicitement la propriété de l'objet à
laquelle
on fait référence (dans notre cas L'objet : "Range"), la procédure soumise
fonctionne rondement. Si j'utilise la propriété explicite ".Value" de
l'objet Range
dans la même procédure, le résultat est errronné. De là à conclure de la
non-nécessité d'utiliser la propriété .Value2, il n'y a qu'un pas.

Je ne conteste pas le brio de ton explication et la clarté de ton code avec
".value2"
mais je voulais simplement dire à l'ami Jac que "Juste à voir... on voit
bien ...." est loin
d'être évident... et qu'il faut souvent gratter un peu pour en saisir la
quintescence.

'-------------------------
Sub test()
Dim LaDate As Date, X
LaDate = CDate("14/08/2008")
X = Application.Match(CLng(LaDate), Range("A1:A25"), 0)
End Sub
'-------------------------

Salutations!

P.S- C'est un plaisir d'avoir ce type de discussion.

> En supposant que dans la plage A1:A25, on a des dates reconnues par excel,

> lorsque l'on omet de nommer explicitement la propriété de l'objet à
> laquelle
> on fait référence (dans notre cas L'objet : "Range"), la procédure soumise
> fonctionne rondement. Si j'utilise la propriété explicite ".Value" de
> l'objet Range
> dans la même procédure, le résultat est errronné. De là à conclure de la
> non-nécessité d'utiliser la propriété .Value2, il n'y a qu'un pas.

Que je ne franchis pas !
De cet exemple parmi d'autres des (in)conséquences du peu de rigueur du langage
VBA dont je parlais (les propriétés par défaut sont une vraie plaie de mon point
de vue), je ne tire pas la même conclusion que toi : j'essaye chaque fois que je
le peux de rappeler au "novice" dont tu parles l'existence des propriétés
multiples de certains objets (Range en est bien pourvu) et l'intérêt de leur
utilisation selon les résultats attendus.
Je trouve ça agaçant que la ligne de code que tu proposes

X = Application.Match(CLng(LaDate), Range("A1:A25"), 0)

fonctionne sans erreur et sans raison rationnellement compréhensible puisque

X = Application.Match(CLng(LaDate), Range("A1:A25").Value, 0)

devrait fonctionner (Value étant la propriété par défaut) mais provoque une erreur.
Je _suppose_ que, les données n'étant pas du même type (Long pour CLng(LaDate)
et Double pour les dates de Range("A1:A25")), VBA cherche à éviter l'erreur et
"glisse" automatiquement de Value à Value2 lorsqu'aucune propriété n'est précisée.
Mais je trouve qu'en être réduit à ce genre de spéculation pour comprendre
"pourquoi ça marche" est très insatisfaisant et je préfère proposer

X = Application.Match(CLng(LaDate), Range("A1:A25").Value2, 0)

parce que là je _sais_ pourquoi ça marche !

FS
---
Frédéric Sigonneau
http://frederic.sigonneau.free.fr

michdenis a écrit :

| Je suis très sensible à ta bénédiction, maître Denis !

**** J'espère...! ;-)))

Et dans le cas où

> la date affichée dans la cellule provient d'une format de
> ce type : =TEXTE("11/01/06";"JJ/MM/AA"), la méthode proposée ferait
> aussi couic...;-)))

| Ah, ben, évidemment ! Si on dit qu'on cherche une date mais qu'en réalité
il
| faut comprendre qu'on cherche du texte, c'est sûr que ça va pas marcher

**** L'objectif était de faire comprendre que de se fier sur ce qui est
affiché
dans la plage de cellules n'est pas suffisant pour qu'une procédure
donnée
fonctionne... cela s'inscrivait à la suite du commentaire fait sur la
proprosition de JB !

> je me demande de la pertinence d'utiliser
> la propriété Value2 de l'objet Range dans cette formule

Bonne demande en effet. La propriété Value2 est (injustement) méconnue, même
s'il est vrai qu'elle ne sert pas à grand-chose en dehors de ce cas de
figure.

| Sans compter qu'il faut penser que les objets ont des propriétés, ce que
| malheureusement la grande tolérance du langage VBA aux approximations
| syntaxiques de ses utilisateurs a tendance à leur faire oublier.

**** Tu as parfaitement raison sur ce point sauf que pour un novice il y a
des choses difficiles à comprendre. Exemple :

En supposant que dans la plage A1:A25, on a des dates reconnues par excel,
lorsque l'on omet de nommer explicitement la propriété de l'objet à
laquelle
on fait référence (dans notre cas L'objet : "Range"), la procédure soumise
fonctionne rondement. Si j'utilise la propriété explicite ".Value" de
l'objet Range
dans la même procédure, le résultat est errronné. De là à conclure de la
non-nécessité d'utiliser la propriété .Value2, il n'y a qu'un pas.

Je ne conteste pas le brio de ton explication et la clarté de ton code avec
".value2"
mais je voulais simplement dire à l'ami Jac que "Juste à voir... on voit
bien ...." est loin
d'être évident... et qu'il faut souvent gratter un peu pour en saisir la
quintescence.

'-------------------------
Sub test()
Dim LaDate As Date, X
LaDate = CDate("14/08/2008")
X = Application.Match(CLng(LaDate), Range("A1:A25"), 0)
End Sub
'-------------------------

Salutations!

P.S- C'est un plaisir d'avoir ce type de discussion.

Sur la version Excel 2003 :

A ) L'explorateur d'objet de la fenêtre VBA ne montre plus par
un petit caractère explictite la propriété par défaut
des objets comme c'était le cas pour la version Excel 2000.

B )

| De cet exemple parmi d'autres des (in)conséquences du peu de rigueur du
langage
| VBA dont je parlais (les propriétés par défaut sont une vraie plaie de mon
point
| de vue), je ne tire pas la même conclusion que toi : j'essaye chaque fois
que je
| le peux de rappeler au "novice" dont tu parles l'existence des propriétés
| multiples de certains objets (Range en est bien pourvu) et l'intérêt de
leur
| utilisation selon les résultats attendus.

Afin de m'assurer que je ne prolifère pas trop d'âneries, je joins une copie
de l'explication de M. Rick Rothstein (MVP - VB) sur la problématique
de l'utilisation de la propriété ".Value" dans la ligne de code suivante:

X = Application.Match(CLng(LaDate), Range("A1:A25"), 0)

Versus :

X = Application.Match(CLng(LaDate), Range("A1:A25").Value, 0)

'-------------------------------------
According to the help files for the worksheet MATCH function, this is what
it says about the second argument...

"Lookup_array -- is a contiguous range of cells containing
possible lookup values. Lookup_array must be an array
or an array reference."

Range("A1:A25") meets this definition whereas Range("A1:A25").Value does not
(it is an array of values, not an array of cells containing values).
'-------------------------------------

Voilà !

Salutations.






"Frédéric Sigonneau" <nospam@nospam> a écrit dans le message de news:
OMk6987%23IHA.5048@TK2MSFTNGP05.phx.gbl...

En supposant que dans la plage A1:A25, on a des dates reconnues par excel,

> lorsque l'on omet de nommer explicitement la propriété de l'objet à
> laquelle
> on fait référence (dans notre cas L'objet : "Range"), la procédure
soumise
> fonctionne rondement. Si j'utilise la propriété explicite ".Value" de
> l'objet Range
> dans la même procédure, le résultat est errronné. De là à conclure de la
> non-nécessité d'utiliser la propriété .Value2, il n'y a qu'un pas.

Que je ne franchis pas !
De cet exemple parmi d'autres des (in)conséquences du peu de rigueur du
langage
VBA dont je parlais (les propriétés par défaut sont une vraie plaie de mon
point
de vue), je ne tire pas la même conclusion que toi : j'essaye chaque fois
que je
le peux de rappeler au "novice" dont tu parles l'existence des propriétés
multiples de certains objets (Range en est bien pourvu) et l'intérêt de leur
utilisation selon les résultats attendus.
Je trouve ça agaçant que la ligne de code que tu proposes

X = Application.Match(CLng(LaDate), Range("A1:A25"), 0)

fonctionne sans erreur et sans raison rationnellement compréhensible puisque

X = Application.Match(CLng(LaDate), Range("A1:A25").Value, 0)

devrait fonctionner (Value étant la propriété par défaut) mais provoque une
erreur.
Je _suppose_ que, les données n'étant pas du même type (Long pour
CLng(LaDate)
et Double pour les dates de Range("A1:A25")), VBA cherche à éviter l'erreur
et
"glisse" automatiquement de Value à Value2 lorsqu'aucune propriété n'est
précisée.
Mais je trouve qu'en être réduit à ce genre de spéculation pour comprendre
"pourquoi ça marche" est très insatisfaisant et je préfère proposer

X = Application.Match(CLng(LaDate), Range("A1:A25").Value2, 0)

parce que là je _sais_ pourquoi ça marche !

FS
---
Frédéric Sigonneau
http://frederic.sigonneau.free.fr

michdenis a écrit :

| Je suis très sensible à ta bénédiction, maître Denis !

**** J'espère...! ;-)))

Et dans le cas où

> la date affichée dans la cellule provient d'une format de
> ce type : =TEXTE("11/01/06";"JJ/MM/AA"), la méthode proposée ferait
> aussi couic...;-)))

| Ah, ben, évidemment ! Si on dit qu'on cherche une date mais qu'en
réalité
il
| faut comprendre qu'on cherche du texte, c'est sûr que ça va pas marcher

**** L'objectif était de faire comprendre que de se fier sur ce qui est
affiché
dans la plage de cellules n'est pas suffisant pour qu'une procédure
donnée
fonctionne... cela s'inscrivait à la suite du commentaire fait sur
la
proprosition de JB !

> je me demande de la pertinence d'utiliser
> la propriété Value2 de l'objet Range dans cette formule

Bonne demande en effet. La propriété Value2 est (injustement) méconnue,
même
s'il est vrai qu'elle ne sert pas à grand-chose en dehors de ce cas de
figure.

| Sans compter qu'il faut penser que les objets ont des propriétés, ce que
| malheureusement la grande tolérance du langage VBA aux approximations
| syntaxiques de ses utilisateurs a tendance à leur faire oublier.

**** Tu as parfaitement raison sur ce point sauf que pour un novice il y a
des choses difficiles à comprendre. Exemple :

En supposant que dans la plage A1:A25, on a des dates reconnues par excel,
lorsque l'on omet de nommer explicitement la propriété de l'objet à
laquelle
on fait référence (dans notre cas L'objet : "Range"), la procédure soumise
fonctionne rondement. Si j'utilise la propriété explicite ".Value" de
l'objet Range
dans la même procédure, le résultat est errronné. De là à conclure de la
non-nécessité d'utiliser la propriété .Value2, il n'y a qu'un pas.

Je ne conteste pas le brio de ton explication et la clarté de ton code
avec
".value2"
mais je voulais simplement dire à l'ami Jac que "Juste à voir... on voit
bien ...." est loin
d'être évident... et qu'il faut souvent gratter un peu pour en saisir la
quintescence.

'-------------------------
Sub test()
Dim LaDate As Date, X
LaDate = CDate("14/08/2008")
X = Application.Match(CLng(LaDate), Range("A1:A25"), 0)
End Sub
'-------------------------

Salutations!

P.S- C'est un plaisir d'avoir ce type de discussion.

En supplément de ce qui a été énoncé :

La propriété "Value" de l'objet Range fonctionne très bien
si la plage de cellules Range("A1:A25") contient des
chaînes de caractères ou des valeurs numériques.

X = Application.Match(Cherche, Range("A1:A25").Value, 0)

Cependant dès que la plage contient des "Dates" ou "Currency"
la propriété "Value" retourne une erreur. Il est à noter que dans
les 2 derniers cas la propriété "Value2" fonctionne.

Disons qu'il y a de ces "nuances" dans Excel qui nous laissent perplexes !!!



"michdenis" <michdenis@hotmail.com> a écrit dans le message de news:
u91egv%23%23IHA.1016@TK2MSFTNGP03.phx.gbl...
Sur la version Excel 2003 :

A ) L'explorateur d'objet de la fenêtre VBA ne montre plus par
un petit caractère explictite la propriété par défaut
des objets comme c'était le cas pour la version Excel 2000.

B )

| De cet exemple parmi d'autres des (in)conséquences du peu de rigueur du
langage
| VBA dont je parlais (les propriétés par défaut sont une vraie plaie de mon
point
| de vue), je ne tire pas la même conclusion que toi : j'essaye chaque fois
que je
| le peux de rappeler au "novice" dont tu parles l'existence des propriétés
| multiples de certains objets (Range en est bien pourvu) et l'intérêt de
leur
| utilisation selon les résultats attendus.

Afin de m'assurer que je ne prolifère pas trop d'âneries, je joins une copie
de l'explication de M. Rick Rothstein (MVP - VB) sur la problématique
de l'utilisation de la propriété ".Value" dans la ligne de code suivante:

X = Application.Match(CLng(LaDate), Range("A1:A25"), 0)

Versus :

X = Application.Match(CLng(LaDate), Range("A1:A25").Value, 0)

'-------------------------------------
According to the help files for the worksheet MATCH function, this is what
it says about the second argument...

"Lookup_array -- is a contiguous range of cells containing
possible lookup values. Lookup_array must be an array
or an array reference."

Range("A1:A25") meets this definition whereas Range("A1:A25").Value does not
(it is an array of values, not an array of cells containing values).
'-------------------------------------

Voilà !

Salutations.






"Frédéric Sigonneau" <nospam@nospam> a écrit dans le message de news:
OMk6987%23IHA.5048@TK2MSFTNGP05.phx.gbl...

En supposant que dans la plage A1:A25, on a des dates reconnues par excel,

> lorsque l'on omet de nommer explicitement la propriété de l'objet à
> laquelle
> on fait référence (dans notre cas L'objet : "Range"), la procédure
soumise
> fonctionne rondement. Si j'utilise la propriété explicite ".Value" de
> l'objet Range
> dans la même procédure, le résultat est errronné. De là à conclure de la
> non-nécessité d'utiliser la propriété .Value2, il n'y a qu'un pas.

Que je ne franchis pas !
De cet exemple parmi d'autres des (in)conséquences du peu de rigueur du
langage
VBA dont je parlais (les propriétés par défaut sont une vraie plaie de mon
point
de vue), je ne tire pas la même conclusion que toi : j'essaye chaque fois
que je
le peux de rappeler au "novice" dont tu parles l'existence des propriétés
multiples de certains objets (Range en est bien pourvu) et l'intérêt de leur
utilisation selon les résultats attendus.
Je trouve ça agaçant que la ligne de code que tu proposes

X = Application.Match(CLng(LaDate), Range("A1:A25"), 0)

fonctionne sans erreur et sans raison rationnellement compréhensible puisque

X = Application.Match(CLng(LaDate), Range("A1:A25").Value, 0)

devrait fonctionner (Value étant la propriété par défaut) mais provoque une
erreur.
Je _suppose_ que, les données n'étant pas du même type (Long pour
CLng(LaDate)
et Double pour les dates de Range("A1:A25")), VBA cherche à éviter l'erreur
et
"glisse" automatiquement de Value à Value2 lorsqu'aucune propriété n'est
précisée.
Mais je trouve qu'en être réduit à ce genre de spéculation pour comprendre
"pourquoi ça marche" est très insatisfaisant et je préfère proposer

X = Application.Match(CLng(LaDate), Range("A1:A25").Value2, 0)

parce que là je _sais_ pourquoi ça marche !

FS
---
Frédéric Sigonneau
http://frederic.sigonneau.free.fr

michdenis a écrit :

| Je suis très sensible à ta bénédiction, maître Denis !

**** J'espère...! ;-)))

Et dans le cas où

> la date affichée dans la cellule provient d'une format de
> ce type : =TEXTE("11/01/06";"JJ/MM/AA"), la méthode proposée ferait
> aussi couic...;-)))

| Ah, ben, évidemment ! Si on dit qu'on cherche une date mais qu'en
réalité
il
| faut comprendre qu'on cherche du texte, c'est sûr que ça va pas marcher

**** L'objectif était de faire comprendre que de se fier sur ce qui est
affiché
dans la plage de cellules n'est pas suffisant pour qu'une procédure
donnée
fonctionne... cela s'inscrivait à la suite du commentaire fait sur
la
proprosition de JB !

> je me demande de la pertinence d'utiliser
> la propriété Value2 de l'objet Range dans cette formule

Bonne demande en effet. La propriété Value2 est (injustement) méconnue,
même
s'il est vrai qu'elle ne sert pas à grand-chose en dehors de ce cas de
figure.

| Sans compter qu'il faut penser que les objets ont des propriétés, ce que
| malheureusement la grande tolérance du langage VBA aux approximations
| syntaxiques de ses utilisateurs a tendance à leur faire oublier.

**** Tu as parfaitement raison sur ce point sauf que pour un novice il y a
des choses difficiles à comprendre. Exemple :

En supposant que dans la plage A1:A25, on a des dates reconnues par excel,
lorsque l'on omet de nommer explicitement la propriété de l'objet à
laquelle
on fait référence (dans notre cas L'objet : "Range"), la procédure soumise
fonctionne rondement. Si j'utilise la propriété explicite ".Value" de
l'objet Range
dans la même procédure, le résultat est errronné. De là à conclure de la
non-nécessité d'utiliser la propriété .Value2, il n'y a qu'un pas.

Je ne conteste pas le brio de ton explication et la clarté de ton code
avec
".value2"
mais je voulais simplement dire à l'ami Jac que "Juste à voir... on voit
bien ...." est loin
d'être évident... et qu'il faut souvent gratter un peu pour en saisir la
quintescence.

'-------------------------
Sub test()
Dim LaDate As Date, X
LaDate = CDate("14/08/2008")
X = Application.Match(CLng(LaDate), Range("A1:A25"), 0)
End Sub
'-------------------------

Salutations!

P.S- C'est un plaisir d'avoir ce type de discussion.