Discussion :

[Pierre Fauconnier]

[...]
Personnellement, je n'utilise jamais le ElseIf qui pour moi est rapidement indigeste. Je privilégie l'usage du Select Case

Si je peux me permettre...

ElseIF et Select Case ne sont pas interchangeables. On utilisera ElseIf lorsque l'on doit tester des conditions sur des expressions différentes, et Select Case lorsque l'on devra tester plusieurs valeurs d'une même expression.

Code :

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

1
2
3
4
5
6
7
8
9
10
If X= ... then
  ...
  ...
ElseIF Y = ... then
  ...
  ...
Else ' aucune des deux conditions remplies
  ...
  ... 
End If

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Select Case Expression
  Case Valeur1 ' sous-entendu Expression = Valeur1
    ...
    ...
  Case Valeur2 ' sous-entendu Expression = Valeur2
    ...
    ...
  Case Else ' sous-entendu Expression <> Valeur1 ET expression <> Valeur2
    ...
    ...
End Select

La construction Select Case permet d'éviter la répétition de l'expression lorsque les tests successifs s'appuient sur la même expression. C'est donc, dans un cas particulier, une autre façon d'écrire les If... ElseIf...


Le code Select Case vu plus haut pourrait s'écrire avec des If.. ElseIf, mais oblige alors à répéter l'expression (qui pourrait être autre chose qu'une simple variable)

Code :

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

1
2
3
4
5
6
7
If Expression = Valeur1 then
  ...
ElseIf Expression = Valeur2 then
  ...
Else
  ...
End If

Ma remarque rejoint celle sur les boucles dont je parlais tout à l'heure. Chaque type de boucle a sa raison d'être et normalement, même si le résultat peut revenir au même, on ne les interchange pas (même si on peut le faire sur le plan technique) et on les utilise à bon escient. Les constructions If... ElseIf et Select Case ont leur raison d'être et doivent être utilisées pour ce pourquoi elles ont été créées, et ce n'est que dans certains cas particuliers qu'on peut (techniquement) les interchanger. Je pense personnellement qu'il est important d'u, bien que pense qu'il ne faut pas le faire si on veut écrire du beau code et qu'il faut utiliser les constructions de code en fonction de ce que l'on souhaite réaliser, pour écrire un code lisible et qui permet au lecteur du code (qui est peut-être la même personne que celle qui va le maintenir) de comprendre l'intention et la finalité du code produit.

My 2 cents

[Pierre Fauconnier]

[...]
Oui Pierre si c'était organisé en colonne pas de problème mais c'est pas le cas [...]

Dans ce cas, la première chose à faire est de réorganiser en colonnes (comme tu le préconisais). On ne construit pas un code sur un classeur mal conçu. Il est moins coûteux de remettre le classeur d'équerre que de construire du code sur une conception qui ne tient pas la route (considération technique et pas du tout une attaque personnelle). On est toujours gagnant à procéder ainsi.

Avec la conception que je propose, on peut ajouter n'importe quelle racine de code sans RIEN MODIFIER à la structure du classeur ou au code VBA qui manipule le classeur. Avec des colonnes différentes par type, on est obligé de modifier le code VBA pour tenir compte des nouvelles colonnes lorsque de nouveaux type apparaîtrons, sauf à monter une usine à gaz en VBA.

Si l'on n'est pas responsable des données que l'on reçoit ni de leur agencement, on est responsable de la façon dont on les traite, et rien n'empêche de les remettre d'équerre avant de les traiter et de les analyser.

En procédant comme je le propose, on se donne la possibilité de profiter des outils natifs d'Excel (TCD, Power Query, Formules, ...) alors qu'en s'appuyant sur une conception fragile car non conforme, on s'oblige à créer du code qui lui aussi, sera inévitablement fragile.

[Igloobel]

Et on peut même utiliser la formule =RECHERCHEV() à condition que la liste des données soit dans l'ordre.

si la liste est triée comme ceci

Number	version
900-20	type 1
900-21	type 1
900-22	type 1
900-23	type 1
900-32	type 2
900-56	type 4
900-98	type 3
900-99	type 3

alors la formule suivante fonctionne parfaitement (j'ai testé et repris ton mini tableau Pierre)

=RECHERCHEV(E2;$A$2:$B$9;2) (avec valeur proche)

[Pierre Fauconnier]

Il n'est pas nécessaire que les données soient dans l'ordre. Il suffit d'utiliser Faux comme quatrième paramètre de Recherchev. Mais je préfère index-equiv (voir mon billet de blog à ce sujet).

[Igloobel]

Il n'est pas nécessaire que les données soient dans l'ordre. Il suffit d'utiliser Faux comme quatrième paramètre de Recherchev. Mais je préfère index-equiv

Ah je suis désolé de te contredire mais vu que l'on a pas les même valeurs dans la colonne A et E il faut bien faire une recherche avec les valeurs proches et donc Vrai (ou omis) et donc trié.

mais cela n'enlève en rien le fait Index-Equiv c'est très bien aussi !

bonne fin de journée

[Pierre Fauconnier]

Valeur proche, que ce soit avec RechercheV ou avec Equiv, sert à trouver la ligne de la plage à laquelle appartient une valeur (en recherchant la valeur inférieure la plus proche). On n'est pas dans ce cas ici, car on cherche la valeur exacte et on doit mettre FAUX, ce qui permet à la liste de ne pas être triée. La solution que je proposais avec Index/Equiv utilisait aussi la valeur exacte (troisième paramètre de Equiv = 0).

Dans le cas présent, il serait même préjudiciable d'utiliser la valeur proche car, en cas de mauvais encodage du code, on pourrait se retrouver avec un mauvais type.

Voici un exemple qui utilise RECHERCHEV avec les données non triées dans la première colonne du tableau des types.

[Pierre Fauconnier]

Je vais essayer mais je doute que ça réponde à mon problème en finalité.

Perso, je n'en doute pas un instant, si tu mets en place une bonne conception de classeur. On peut réaliser le travail par vba si la manipulation s'inscrit dans un processus de préparation plus complet, mais la structure à mettre en place est celle que je préconise si tu veux pouvoir évoluer avec ton classeur à moindre coût

Nul doute que des solutions full vba existent et peuvent se greffer sur ta conception avec les quatre listes séparées, mais elles seront toujours plus coûteuses qu'une bonne conception et qu'une bonne utilisation des outils natifs d'Excel, surtout pour un non-informaticien...

Comme tu le vois ici, si tu doit utiliser un nouveau préfixe avec un nouveau type, il te suffit de l'ajouter dans le tableau des types, et les codes qui vont correspondre à ce nouveau préfixe vont directement récupérer le nouveau type, sans que tu aies rien à modifier à la structure de ton classeur, et sans que tu doives utiliser ou modifier du code VBA.




Qui plus est, les codes proposés utilisent le hard coding (l'utilisation de valeurs métier dans le code) et la structure de ton code dépend intimement de tes données (autant de ElseIf ou de Case qu'il y a de colonnes de types) et doit être modifiée lors de l'ajout d'un nouveau type.

Si vraiment on devait récupérer le type d'un code donné en VBA, on utiliserait alors une fonction perso qui s'appuierait sur Index/Equiv, histoire d'éviter la boucle. Attention, dans mon code, j'ai mis un _ dans la référence structurée (t_Types[_Code],0))

Code :

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

1
2
3
4
5
6
Function GetPrefix(Number As String) As String
  Dim Formula As String
 
  Formula = "=INDEX(t_types[Type],MATCH(""" & Left(Number, 6) & """,t_types[_Code],0))"
  GetPrefix = Evaluate(Formula)
End Function

Mais je pense qu'il faut d'abord que tu détermines si tu as besoin de VBA et si oui, à quel moment du traitement et pour faire quoi, de manière récurrente ou en one-shot...