Condition "Or" avec format date et texte

Bonjour,

Je tente de faire en une seule ligne 2 conditions même j'ai un problème d'incompatibilité de type.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

Public Sub MoisTest()   With ThisWorkbook.Sheets("Feuil1") For i = 3 To 20 If (.Cells(i, 16).Value = "ok") Or (Month(.Cells(i, 16).Value) = 12) Then Debug.Print .Cells(i, 16) & " ok" End If Next i End With   End Sub

---

Passer par 2 conditions successives, je sais faire mais j'aimerais éviter d'alourdir la lisibilité du code en doublant le nombre de ligne à chaque fois.

Les cellules ont un format que je peux modifier si c'est vraiment nécessaire : dd/mm/yy

Salut buzz73 et le forum
À ma connaissance tu es obligé de passer par 2 tests successifs, tes variables pouvant être du texte, tu ne peux pas tester le mois, ça déclenche une erreur
A+

Avec un peu d'astuce il est possible de faire le test sur une seule ligne sans déclencher d'erreur en remplaçant la deuxième partie par ceci:

Code:

---

Month(IIf(IsDate(.Cells(i, 16).Value), 10, .Cells(i, 16).Value)) = 12

---

En supposant bien sûr que le contenu de ta cellule est reconnu comme étant une date. ;)

Attention: à utiliser avec parcimonie, car Month(10) correspond à une date réelle.

Effectivement, Excel teste toutes les conditions avant de retourner un résultat donc ça plante.

J'ai essayé la solution de decondelite mais ce n'est pas mois qui remplis les cellules... donc parfois il y a des surprises.
Finalement, je suis revenu aux tests successifs.

Merci à vous deux pour vos réponses!

La solution que je te propose part du principe que le contenu de ta cellule est interprétable ou non comme étant une date. Ca reconnaît donc également les nombres comme étant des dates: la preuve Month(10) fonctionne très bien, alors que pourtant Month attend un argument de type Date.

Pour te donner plus de chances et de précision, vérifie avec un test interne supplémentaire si ta cellule contient un simple nombre ou non. ;)

J'ai testé, ça marche effectivement.
Merci!
Par contre, il semblerait qu'il faille préférer le "if... then...else" (d'après des articles lus mais je n'ai pas compris les nuances). Votre avis?

Mon avis est que tout dépend:
-des possibilités de contenu que tes cellules peuvent avoir
-du niveau de contrôle de la saisie que tu comptes utiliser: tu ne contrôles rien, tu contrôles comme un barbare ou entre les deux
-de l'importance que tu attaches au niveau de l'intelligibilité du code
-de l'importance que tu attaches au niveau du nombre de niveaux de blocs (un niveau de bloc c'est une condition if ouverte, beaucoup de niveau signifie beaucoup de blocs ouverts)
-de l'importance que tu attaches au niveau des performances du code


De ceci, on en retire que:
-la solution que je te propose, en incluant un contrôle de format nombre, suppose que ton utilisateur peut rentrer absolument n'importe quoi, ce qui est généralement le cas
-cette solution peut être raccourcie selon si tu estime que l'utilisateur rentrera n'importe quoi ou pas (que ce soit de son plein gré ou que tu restreignes la saisie)
-cette solution est conçue pour avoir un nombre de niveaux de blocs le plus petit possible, et donc le moins possible d'indentations à droite (quand il y a beaucoup de niveau, lire le code ou coder de manière à avoir tout de visible dans la largeur peut devenir très difficile: expérience personnelle à l'appui)
-en revanche cette solution n'est pas du tout prévue dans l'optique d'optilmiser les performances, en ce sens qu'elle fera systématiquement tous les calculs
-la solution d'imbrication de If sera plus performante, mais utilisera plus de niveaux de blocs (logique...)


Tout ceci étant dit, je vois qu'à priori ton code n'est pas du genre "je suis lourd et super-avide de temps de processeur", et que donc si tu utilise ma solution ça ne mettra quand même pas 100 ans à s'exécuter.

Certaines personnes sur ce forum sont des maniaques de performance (je dis ça sans vouloir les blesser hein), et te diront qu'il faut systématiquement imbriquer des If quand c'est possible, mais bon pour ma part je pense qu'il faut plutôt faire la part des choses et ne chercher à optimiser le code par tous les moyens que quand cela s'avère réellement nécessaire.

ça c'est de la réponse! :mrgreen:
j'ai appris plein de choses dans la foulée.
Je te remercie.