Commentaires

Salut Pierre,

Merci bien pour ce retour qui confirme mon doute aussi

Bon week-end

Superbe tes billets

Salut Malick,

Merci de passer par mon blog.

En fait, je dis dans le texte, mais de manière trop discrète, qu'il s'agit de fonctions disponibles dans les versions 365 et 2019 d'Excel. La version 2016 ne dispose donc ni de CONCAT ni de JOINDRE.TEXTE.

Désolé pour toi.

Je vais modifier le titre et préciser explicitement les versions pour lesquelles ces fonctions sont disponibles

Salut Pierre,

Comme à mes habitudes, j'essaie d'appliquer tes astuces

Cependant, la fonction JOINDRE.TEXTE() n'est pas présente sur ma version d'Excel Professionnelle 2016



Quelque chose à activer ?

Peut-être est-ce sur 2019 seulement, car je viens de lire ceci :

Remarque : Cette fonctionnalité est disponible sur Windows ou Mac si vous avez Office 2019, ou si vous avez un abonnement Microsoft 365. Si vous êtes un abonnéMicrosoft 365, assurez- vous que vous disposez de la dernière version d’Office.

Bonjour,
D'abord grand merci pour vos nombreux travaux souvent très intéressants et vos grandes qualités de pédagogue !
Je suis un vieil "amateur éclairé" d'Excel et de VBA et je suis avec intérêt les évolutions actuelles d'Excel et VBA. Je travaille sous Windows 7 (hé oui !) avec la dernière version de Microsoft 365.
Je constate les rapides évolutions et j'avoue être parfois dépassé par les orientations récentes et actuelles prises par Microsoft. Par exemple, j'ai mis du temps à comprendre que Power Query et Power Pivot sont deux choses différentes, et je ne parle pas de l'apparition récente de Power Apps et de la mise à disposition gratuite d'Office en version allégée ...
J'ai bien noté aussi que vous vous désoliez du peu d'utilisation d'une technique vieille de 13 ans....

Dans ces conditions, je trouverais déjà utile que vous actualisiez votre billet (qui n'a pourtant guère qu'un an d'âge !).
Mais j'aimerais bien aussi que vous donniez (dans un autre billet ou sur le forum ?) votre jugement d'expert sur toutes ces évolutions concernant Office et Excel et d'apporter des réponses à des questions telles que :
- est-il réaliste de laisser penser que ces nouvelles évolutions ne nécessitent soi-disant pas de développement VBA (sous-entendu de personnels spécialisés ?) sous prétexte que "tout peut se faire à la main" ?
- quand on constate le grand décalage entre la publication de nouvelles fonctionnalités et leur utilisation réelle, ne peut-on penser que l'on va ajouter un peu plus de confusion dans les esprits avec la débauche actuelle de nouveautés ?
- quid des performances par rapport aux solutions actuellement utilisées ?
- nécessité d'évolutions des matériels et logiciels de connexion, de sécurité, de connexion au "cloud", ...

Merci d'avance de votre intérêt aux questions que je pose !
YD

Bonjour Malick,

C'est bien tardivement que je réponds à ton intervention. J'espère que tu vas bien

Merci pour tes encouragements qui me donnent envie de continuer à écrire des billets. On a parfois l'impression d'écrire "pour du vent", et il est donc toujours agréable de savoir que le billet sert à quelqu'un.

Au plaisir de te croiser sur les forums

Trés clair et trés efficace.
et j'aime bien le "pensez Excel avant de penser VBA" cela me parle...

Merci et bonne journée

Merci Denis. J'espère que cette astuce donnera plein d'idées d'utilisation de ces nouvelles fonctions, car elles simplifient la vie du formuliste Excel comme du codeur VBA, comme je le montre dans d'autres billets ou des réponses sur le forum:

• Coder plus facilement des combobox et listbox grâce aux fonctions XL365;
• Combiner les fonctions XL365 pour extraire des données sans doublons;
• Trier les lettres présentes dans une cellule.

Apparemment, saisir une heure telle que 10:25, c'est tellement compliqué qu'il faut passer par des "astuces" pour "simplifier" la saisie...

Misère... ^^

Belle astuce avec la fonction ALEA.ENTRE.BORNES et les numéros de lignes

Dites les gars, faut arrêter.

C'est pas parce que je m'appuie sur 25 ans de pratique et que je suis élitiste dans le choix des tutos qu'il faut me frotter la manche.

C'est vrai que j'ai dû réfléchir longtemps, mais j'aime bien partager, surtout quand j'ai été obligé de lire plein de tutos et de suivre des formations qui m'ont coûté un pognon de dingue... Je suis comme ça moi: Quand j'ai mis 20 ans d'élitisme à comprendre un truc qu'un enfant de 4 ans comprend en 2 minutes, je partage...

Bonjour Pierre,

Merci beaucoup pour cet excel'lent tutoriel.

J' ai fouillé le forum en long et en large, je commençais à ne plus voir le bout du tunnel,pour trouver la meilleur façon d'insérer une date dans une cellule/contrôle. Tu es mon sauveur.

Ps: La bonne blague, ça ne fonctionne pas!.. Oups , mais non c'est moi,je n'avais pas mis le "Num Lock".

Au plaisir de te lire,
Michael

Bonjour Pierre,

Comme tout bon fainéant, je mets la colonne au format souhaité et
ensuite je me contente de saisir 30/10 ou 1/5 ... même pas besoin du 2020 ni des zéros devant le jour ou le mois !
C'est vraiment un effort incommensurable

Bonsoir Pierre,

Je viens de consulter ce billet.
Très belle fonction qui intègre les WorksheetFunction de VBA. Sauf erreur, toutes les fonctions natives du tableur ne le sont pas. J'ai donc vérifié.

Dans ma contribution,

ces 4 lignes

Code :

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

1
2
3
4
5
Dim tb() As Variant
ReDim tb(1 To rng_dest.Count)
tb = Application.Transpose(rng_dest)

liste_adresses = Join(tb, ";")

sont remplacées par 1 seule

Code :

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

liste_adresses = Application.WorksheetFunction.TextJoin(";", True, rng_dest)

ou bien, si l'on intègre les 2 fonctions citées TRIER et UNIQUE

Code :

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

liste_adresses = Evaluate("=TEXTJOIN("";"",TRUE,SORT(UNIQUE(" & rng_dest.Address & ")))")

Je m'empresse donc de l'actualiser.

Une remarque au demeurant,

TRI retourne une erreur. Ce car Excel considère, du moins sur sa version 2016, comme "taux de rendement interne"
Il me faut écrire TRIER

=JOINDRE.TEXTE(";";VRAI;TRIER(UNIQUE(T_liste2[détail_liste])))

Merci.

Envoyé par MarcelG

[...]

Je préfère, et de loin,

Code :

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

Cbx_Ville.Listindex

.[...]

Nous sommes bien d'accord. J'ai pris aussi l'habitude de préfixer mes contrôles et de leur donner un nom explicite.

Chimay bleue (ne pas abuser car c'est du costaud), c'est la brune. L'autre, la blonde un peu ambrée, c'est la Triple Karmeliet... Ne pas abuser non plus...

Une autre, pas mauvaise du tout mais un peu plus traître pour moi, c'est la Rochefort 10 (un peu plus de 11°). Une tuerie à boire avec modération...

Cela étant, aller en Toscane ou dans les Pouilles pour découvrir les jus de raisin de là-bas ne serait pas pour me déplaire...

Bonne soirée et

D'accord, Pierre.
A tort, je confondais Propriété et mot clé. Je voulais simplement signifier que Value fait partie du langage VBA.
Don't Act.

Au demeurant, cet échange sous-entend un autre sujet sur lequel je m'interroge bien souvent.
A savoir, la dénomination des objets.
Et je l'ai d'ailleurs maintes fois mentionné sur le forum.

On voit trop de

Code :

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

Combobox1.Listindex

.

Je préfère, et de loin,

Code :

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

Cbx_Ville.Listindex

.

Ces considérations rentrent dans un cadre général qui concerne la clarté, donc la rigueur dans la manière de coder. Voir mon dernier billet.

Mais tout cela constitue un autre débat.

Bonne soirée à toi.

Et n'oublie pas la Chimée Bleue (l'autre marque, je ne m'en rappelle plus.)
Il devrait y avoir un sous forum boissons (bières, vins, alcools...)

Envoyé par MarcelG

[...]
Si l'objet en question est Range, cela donne

Code :

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

Value.Value

[...]

On ne pourra jamais éviter cela à 100%. Pour moi, le principe consiste à ne pas utiliser de mots-clé VBA, ou plus généralement de mots-clé du langage utilisé. Value n'est pas un mot-clé VBA, mais la propriété d'un objet particulier d'une bibliothèque particulière, donc je n'ai personnellement aucun problème à l'utiliser comme nom de variable ou de propriété dans mes propres développements.

Dans la mesure où je systématise mon approche et mon code autant que possible, j'ai dû faire un choix et appeler Value la valeur que l'on attribue à une propriété d'un objet ne m'a pas paru idiot ou bizarre (la preuve, c'est que les ingénieurs de MS l'on fait avec un objet Range)...

Les appellations des procédures, fonctions, propriétés, variables (ce que sont les arguments d'une fonction), modules et classes seront toujours sujettes à caution. Certains mettent des appellations anglaises ou (mal) anglicisées, d'autres ne jurent que par le français, d'autres écrivent des abréviations dont eux-mêmes ne connaissent plus le sens lorsqu'ils se replongent dans le code six mois plus tard ...

Le choix des uns paraîtra bizarre aux autres, et vice versa. Perso, un Value.Value ne me gêne pas, comme un range("a1").Parent.Parent pour remonter au classeur ne me gêne pas

'ai décidé une fois pour toutes d'appeler Value un paramètre passé à une propriété d'un objet...

Oui mais ne crois-tu que, pour la plupart des néophytes dont je suis, cette écriture puisse porter à confusion?

Si l'objet en question est Range, cela donne

Code :

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

Value.Value

C'est juste un avis.

Bonjour Marcel

Envoyé par MarcelG

[...]pour laquelle, au passage, je n'ai pas aperçu de fichier joint[...]

Cette discussion est polluée par des gens qui n'ont pas compris grand chose aux tableaux structurés, aux bases de données et à la programmation, et qui s'imaginent que l'informatique, c'est de la philosophie de café de commerce où même les plus cons (surtout les plus cons) ont droit de parole et pensent que l'informatique est "relative", qu'on peut faire n'importe quoi et que toutes les idées et pratiques se valent.

Envoyé par MarcelG

[...]Tu fais allusion, dans ce billet, à une discussion. En as-tu le lien?[...]

En cliquant sur le bouton à droite de mon nom, tu atterris sur la discussion...

Envoyé par MarcelG

[...]
Ici, dans le code du formulaire, que représente "Value" en tant que paramètre des 2 Property.

Sans doute par ignorance, j'ai du mal à m'y retrouver, surtout lorsque des mots clés de VBA sont ainsi utilisés.[...]

Value n'est pas un mot-clé de VBA. Dans le cas présent, c'est simplement le nom de l'argument que je passe à la propriété. Pour éviter de me gratter l'occiput à trouver des noms de paramètres, j'ai décidé une fois pour toutes d'appeler Value un paramètre passé à une propriété d'un objet...

Au temps pour moi!

Tu injectes dans les Property les valeurs définies dans le module standard. D'où d'ailleurs Property Let
C'est le "Value" qui m'interpellait.

Perso, je préfère ce type de développement à celui que tu exposais dans la discussion que j'ai consultée.

D'autant qu'il est adaptable à x combobox.

A plus tard.

Bonjour Pierre,

Je me réfère à ce développement par rapport à cette discussion (pour laquelle, au passage, je n'ai pas aperçu de fichier joint).

Tu fais allusion, dans ce billet, à une discussion. En as-tu le lien?

Ici, dans le code du formulaire, que représente "Value" en tant que paramètre des 2 Property.

Sans doute par ignorance, j'ai du mal à m'y retrouver, surtout lorsque des mots clés de VBA sont ainsi utilisés.
Je ne vois pas explicitement la logique de ce code. Trop fort pour moi

Merci pour ton retour.

Cordialement.

Marcel