Question de syntaxe auux anciens en général et à Thierry en particulier

Salut,

En premier, concernant la concision, pourquoi utiliser la ligne
Dim L as Integer
puisqu'il suffit d'écrire L!= ... lors du premier appel de la variable L pour que celle-ci devienne Integer.

En second, ta solution semble parfaitement convenir, sauf peut-être la dernière ligne, où il peut être utile de spécifier la feuille.
ComboBox1.RowSource = "Feuil1!A2:A" & L


Mais bon, si on veut faire concis (et pas forcément lisible) :
Private Sub Ini()
ComboBox1.RowSource = "Feuil1!A2:A" & Sheets("Feuil1").Range("A65536").End(xlUp).Row
End Sub

Comme ça, une seule ligne de code, et aucune variable utilisée ;o))

Bonne matinée

Rai

Bonjour le fil

C'est sur que on peut être concis tel que le fait Rai.

Ensuite le problème est de trouver le compromis entre éviter des lignes inutiles de code et une relecture facile du code.

Par exemple avec le L! si on rencontre un problème du genre la dernière ligne est 50000 donc plus un integer il est peut-être plus facile de retrouver une déclaration de variable du style Dim L as Integer que le L!.

Chacun voit ce qui est plus facile pour lui dans sa compréhension et je le répète trouver le compromis entre concision et relecture, tout en sachant que des choses qui paraissent concises à un moment peuvent le devenir beaucoup moins par la suite. Par exemple la ligne :
ComboBox1.RowSource = "Feuil1!A2:A" & Sheets("Feuil1").Range("A65536").End(xlUp).Row
est beaucoup plus concise que de passer par plusieurs lignes pour la récupération de la ligne dans une variable L. Mais si par la suite ton programme évolue et que tu utilises cette ligne plusieurs fois il est plus facile de l'avoir récupérer d'abord dans une variable.

Voilà ce que j'en pense avec le peu d'expérience que j'ai.

Bonne journée

Pascal

non, si tu écris L!, tu ne crées pas un Integer, mais un Single. Pour avoir un Integer, écris L%

personnellement je n'utilise jamais la propriété RowSource, donc j'écrirais ça plutôt ainsi :

With ThisWorkbook.Worksheets("Feuil1")
ComboBox1.List = .Range("A2", .Range("A65536").End(xlUp)).Value
End With

re-,

Yep, j'abonde dans le sens de Pascal.
Comme je l'ai écrit : "Si on veut faire concis ... et pas forcément lisible"

Par ailleurs, dans de nombreux cas concision n'est pas non plus synonyme de rapidité :
- rapidité de programmation (ou de modif) pour cause de mauvaise lisibilité
- rapidité de déboguage : ya bien une ligne surlignée fluo ... mais elle comporte tellement de méthodes et propriétés qu'on arrive pas à discerner laquelle provoque une erreur
- rapidité d'exécution : plutôt que de faire parcourir une feuille complète pour un calcul, on peut en stocker des parties en Array, ou on peut faire des tests de fin (pour limiter la portée de la procédure)

et j'en oublie...

En général, je commence par bien scinder tous les éléments, et ensuite quand tout est au point, je regarde si la concision s'impose et où.
Après,c'est aussi un vieux jeu entre programmeurs ... à celui qui trouvera la ligne la plus concise pour faire une action ...

Bonne matinée

Rai

Salut à tous,

TI, peut tu me donner les avantage de list par rapport à rowsource. Ne connaissant pas list pour le moment j'utilise rowsource avec quelque difficulté par moment. Donc Si list est plus souple d'utilisation, je suis preneur.

A+ Wilfried ;op

Salut Ti,

Merci pour la correction, ! et % sont très différents !!
Je vais courir aller me chercher un nouveau café avant de poster de nouveaux messages ;o))

---------------

Autrement une question, simple curiosité :
Pour quelles raisons préfères-tu .List à .Rowsource ??

Ou si tu préfères :
Des quels cas préfères-tu ... ?

merci

Rai

Question d'habitude.
Manipuler des listes, même sur de grandes plages, est immédiat (Excel excelle en ce domaine...), d'autre part, ça me permet de réorganiser par programme mes listes comme je le désire, sans toucher aux données originales sur la feuille (suppression des doublons, tri de la liste etc.).
Trier une liste avec un QuickSort est l'affaire d'un souffle, supprimer les doublons aussi, etc.

Bon, pour en revenir à la question de début, là encore on voit que la meilleure méthode, c'est avant tout celle qu'on manipule le plus volontiers, et dans laquelle on se retrouvera le plus facilement, même après 6 mois ou un an. Souvent quand je commence un programme, je décompose les étapes en utilisant beaucoup de variables (une variable Feuille, Plage, Liste etc.) Ensuite, une fois que ça tourne bien, on peut faire un peu le ménage, mais comme le dit Pascal, créer une variable ne coûte rien en temps et peut permettre d'obtenir un code bien plus lisible.
Pour vous en convaincre, allez voir certains programmes en C, tellement condensés que pour comprendre leur fonctionnement le plus simple est souvent de les exécuter en pas à pas.

Personnellement je suis maniaque sur tout ce qui concerne l'écriture et la présentation de mes programmes, mais ainsi, même en mettant très peu de commentaires, je sais que lorsque je remettrai le nez dans un vieux code, tous ces automatismes me permettront de ne pas perdre de temps à retrouver pourquoi j'ai fait telle ou telle chose.

Merci à tous pour vos réponses

Bonne journée

Bonjour à Tous,

J'irai bien entendu dans le même sens que tout ce qui a été annoncé ici. Pour ma part, et spécialement ici, je m'efforce toujours de faire des codes clairs avec un tas de Variables, mêmes si on peut souvent s'en passer. Je me souviens d'ailleurs d'un échange à trois avec Valérie, Ti et Moi, où nous avions convenu que même si on ne défini pas de Variable, VBA les génère quand même de manière implicite, donc en fait ça n'allourdit pas...

Sinon pour la différence entre List et RowSource, regarde cette démo Wilfried :

Lien supprimé

Bon Aprèm
@+Thierry

Merci THierry (et les autres) pour avoir répondu à ma question et pour tout ce que j'apprends en décortiquant tes procédures

François