Discussion :

[Samiess]

Bonjour à tous , je cherche désesperement à créer une comboBox qui va ouvrir mon dossier "A" dont le chemin d'accès est "C:/....../A",
cette comboBox doit afficher tous les fichiers excel de mon fichier , une fois que je selectionne ce fichier sur cette combobox , une msgbox doit s'afficher avec le nom du fichier séléctionner et son chemin d'accès . Je vous prie de bien vouloir m'aider

[Menhir]

Bonjour à tous , je cherche désesperement à créer une comboBox qui va ouvrir mon dossier "A" dont le chemin d'accès est "C:/....../A",
cette comboBox doit afficher tous les fichiers excel de mon fichier , une fois que je selectionne ce fichier sur cette combobox , une msgbox doit s'afficher avec le nom du fichier séléctionner et son chemin d'accès . Je vous prie de bien vouloir m'aider

Pourquoi essayer de réinventer la poudre et ne pas utiliser GetOpenFileName ?
https://docs.microsoft.com/fr-fr/off...etopenfilename

[clementmarcotte]

Bonjour,

Pour en mettre une couche, la meilleure solution c'est de te faire un Activex en VB.net. Parce que là, tu peux hériter de la classe Combobox du Framework .net et ter sauver énormément de programmation.

En VBA, tu ne peux pas hériter de la classe combobox et tu dois te faire un module de classe en partant de zéro…

Donc, aussi bien suivre le bon conseil de Menhir, que je salue au passage.

Mais si c'est un devoir, tu peux oublier tes vacances.

[Arkham46]

Bonjour,

Cela ressemble fort à un devoir.
Dans tous les cas et même si je me trompe, merci de nous fournir un début de travail si vous souhaitez un peu d'aide.
Le forum peut vous aider à apprendre, pas faire votre travail.

@Menhir : oui on fait ça d'habitude

@clementmarcotte : il faut arrêter ce délire avec .net
On ne va forcément pas être d'accord, mais on n'utilise pas .net à toutes les sauces à la moindre difficulté.
Créer un ActiveX n'est pas la meilleure solution : sans doute la plus mauvaise.
Et puis "hériter de la classe Combobox du Framework .net", c'est quoi le scoop ?
Je pourrais dire : "Excel hérite de la classe ComboBox de la librairie MsForms".
Pour afficher une liste de noms fichiers ça suffit bien.

[clementmarcotte]

Bonjour,

@clementmarcotte : il faut arrêter ce délire avec .net

Moi je n'appelle pas cela du délire, j'appelle cela de la réalité objective

On ne va forcément pas être d'accord, mais on n'utilise pas .net à toutes les sauces à la moindre difficulté.

Je n'ai jamais dit le contraire, mais j'ai assez pratiqué les deux pour voir la différence. OK pas pas VBA Access. mais VBA Excel, Word PowerPoint et Publisher, il y a quelques jours. Et même hier soir j'ai dû aider quelqu'un qui s'y connaît en Word à ne pas utiliser les contrôles VB6 parce qu'ils sont incompatibles avec Office 64 bits.

Depuis, Office 2010, et tu le sais, Office est disponible en Version 32 bits et en version 64 bits. Et tu sais également, que Microsoft a décidé de ne pas rendre ses vieux ActiveX 32 bits compatibles avec Office 64 bits. Mais, ces contrôles sont soit déjà installés sur les machines, ou facilement téléchargeables à partir d'adresses largement partagées sur le forum. Et il existe des organisations, et des particuliers qui développent sur des Office à 32 bits en utilisant ces contrôles, des applications qui se plantent sur des machines avec des Office à 64 bits. Tant que tu n'écriras pas un tutoriel sur la façon de se passer des ces contrôles-la sur un Office à 64 bits, ou qu'il n'existera pas une alternative gratuite ou pas chère et compatible 32 bits et 64 bits à ces contrôles, .net demeure une alternative relativement simple et complètement documentée (sur MSDN) pour les parcs hétéroclites d'Office. Et puis si Microsoft rendait compatibles ses vieux contrôles avec tous les Office, la question ne se poserait même pas.

Également, il y a des entreprises qui ont des versions différentes d'Office. Dans ce cas, le problème vient de l'incapacité de VBA de remplacer les références à Office 2019 par celles à Office 2016, ou l'inverse, ou n'importe quelle autre combinaison de versions. Admettons que l'auteur du programme puisse utiliser la bibliothèque Extensibility d'Office pour jouer avec les références. Sauf que cela cause des problèmes de sécurité. Encore là .net offre une alternative relativement simple et documentée sur MSDN pour utiliser Office à partir de net, Les bibliothèques Microsoft.office.interop ont toutes le même GUID depuis Office 2003. Tant que l'on utilise pas une fonctionnalité récente sur une édition trop ancienne, il n'y a pas de guerre de référence. Et puis Visual Studio (.net) peut lire ou écrire directement un fichier Office 2007 et plus récents sans avoir Office installé. Ce n'est pas facile, mais possible. Et puis Visual Studio, peut manipuler un fichier Access le plus simplement du monde, soit avec des assistants, soit avec des requêtes SQL.

Créer un ActiveX n'est pas la meilleure solution : sans doute la plus mauvaise.

Cela dépend de La Commande cachée derrière la question. Il dit qu'il veut un ComboBox avec une série d'autres choses. Où la commande c'est in nouveau Contrôle qui inclus toutes les exigences, et là l'ActiveX ne peut pas être évité. Ou bien, c'est un UserForm avec un combo et d'autres contrôles qui faut ce qui est demandé

Et puis "hériter de la classe Combobox du Framework .net", c'est quoi le scoop ?

En POO, l'héritage est un terme technique lié à la possibilité d'intégrer à une classe les fonctionnalités d'une autre classe, sans tout reprogrammer. En vraie POO, donc en .net et pas en VBA ont peut hériter du Combobox d'origine et lui ajouter la fonctionnalité désirée. Il te reste juste à me prouver que tu peux le faire en VBA

Pour afficher une liste de noms fichiers ça suffit bien.

Justement, la question ne porte pas juste sur la liste de fichier. S'il veut faire tout cela en VBA, on sort du Combobox et on se dirige vers un Userform. En .net on peut avoir un combo qui faut tout cela. Pas facilement, mais on peut


Relis la question. Il veut un combobox

une fois que je selectionne ce fichier sur cette combobox , une msgbox doit s'afficher avec le nom du fichier séléctionner et son chemin d'accès

[chrtophe]

Microsoft a décidé de ne pas rendre ses vieux ActiveX 32 bits compatibles avec Office 64 bits.

Il ne faut donc plus utiliser les ActiveX, les versions 32 bits vont disparaitre peu à peu.

Les ActiveX sont des vieilleries.

[Arkham46]

La demande initiale est certes un peu mal exprimée.
Mais il s'agit sans doute d'une simple liste de noms de fichiers.
Développer un activeX pour cela me semble disproportionné, et ne peut pas être proposé comme meilleure solution.

[Pierre Fauconnier]

Salut.

Comme Arkham, je pense que la demande ne consiste pas à créer un contrôle, mais à alimenter un combobox avec une liste (dans ce cas-ci de fichiers), puis d'afficher le choix dans un mgbox... A mon avis, il faut lire entre les lignes avant de partir sur la création d'un contrôle perso, surtout qu'il est impossible de "créer un contrôle" en VBA, même avec un module de classe perso.

Dans le cas où c'est une question relative à l'alimentation d'un combobox, le problème consiste à créer une fonction qui renvoie la liste des fichiers d'un dossier sous forme de tableau, d'alimenter le combobox avec ce tableau, puis de gérer l'évènement Change du combo pour afficher le choix:

Dans un module standard:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Function getFiles(Path As String)
  ReDim Files(0)
  Dim FileName As String
 
  FileName = Dir(Path & "\*.*")
  Do While FileName <> ""
    If Files(0) <> "" Then ReDim Preserve Files(UBound(Files) + 1)
    Files(UBound(Files)) = Path & "\" & FileName
    FileName = Dir()
  Loop
  getFiles = Files
End Function
 
Sub Test()
  Dim Files
 
  Files = getFiles("e:\temp")
  With UserForm1
    .ComboBox1.List = Files
    .Show
  End With
  Unload UserForm1
End Sub

Dans le module du userform

Code :

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

1
2
3
Private Sub ComboBox1_Change()
  MsgBox ComboBox1.Value
End Sub

Cela étant, je suis d'accord avec Menhir (Hello): Pourquoi faire simple (utiliser ce qui existe) quand on peut faire compliqué?

[clementmarcotte]

Et pour tous ceux qui doutent de ma santé mentale quand je parle de .net en Office. Même Microsoft y croit:

Excel

Word

PowerPoint

Eh oui même Access

Et puis, il y avait un deuxième degré qui n'a visiblement pas été constaté à ma première réponse.

Et puis si sa version d'Excel est récente, il peut aussi essayer avec JavaSript, XML et un contrôle de contenu. Mais quoi qu'il en soit, personne n'a formulé aucun argument crédible sur la façon de remplacer les vieux ActiveX dans des macros sur un Office à 64 bits. Personne n'a prouvé que j'avais tort de préconiser VB.net qui a les mêmes contrôles comme solution de remplacement. À part le DatePicker de Patrick Toulon ou Robert Durupt. Personne d'autre n'a de solution à ce problème, même en me mettant -1. Pour la guerre des références, la seule solution que vous avez c'est create Object. Les gens ont le droit de choisir entre create Objet et VB.net.

Vous avez le droit d'être de la religion VBA avec des œillères. Mais on a aussi le droit d'être de la religion VBA sans œillère ou de la religion solutions pratiques œcuméniques. Personnellement, en l'absence de solution pratique en VBA, j'aime mieux diriger les gens vers une solution pratique en .net que de les abandonner. Mais si voulez léser les clients en les laissant sans solutions au lieu de leur présenter des voies alternatives, tout ce que vous avez à faire c'est de le mettre dans les Règles :

"En l'absence de réponse strictement liée au seul logiciel en cause, on ne répond rien."

Et dès que quelqu'un se plante avec un classeur qui plante par manque de mémoire vive, on ne répond rien

[clementmarcotte]

Il ne faut donc plus utiliser les ActiveX, les versions 32 bits vont disparaitre peu à peu.

Les ActiveX sont des vieilleries.

Mais en attendant, Microsoft les installe visiblement toujours avec ses Office à 32 bits. J'ai remplacé mon disque rigide en décembre dernier. J'ai réinstallé Office 365 (32 buts), mais pas VB6. Mais j'ai quand même ces contrôles en version VB5 (que je n'ai jamais eu) et en version VB6. Même quelqu'un que je connais et qui vient d'écrire un livre sur Word 2019 les a aussi.

[clementmarcotte]

Salut.

Comme Arkham, je pense que la demande ne consiste pas à créer un contrôle, mais à alimenter un combobox avec une liste (dans ce cas-ci de fichiers), puis d'afficher le choix dans un mgbox...

Et moi, après la réponse de Arkham j'ai écrit cela:

Cela dépend de La Commande cachée derrière la question. Il dit qu'il veut un ComboBox avec une série d'autres choses. Où la commande c'est in nouveau Contrôle qui inclus toutes les exigences, et là l'ActiveX ne peut pas être évité. Ou bien, c'est un UserForm avec un combo et d'autres contrôles qui faut ce qui est demandé

Et je n'ai jamais dit qu'il avait tort sur ce point-là.

Cela étant, je suis d'accord avec Menhir (Hello): Pourquoi faire simple (utiliser ce qui existe) quand on peut faire compliqué?

Son premier pouce levé, c'est moi.

[Arkham46]

Quelqu'un m'a mis un -1 au post #4, je suis trop pas content.

@Samiess, si tu es toujours là, précise ton problème qu'on puisse avancer.

[chrtophe]

Je pense que la réponse a été donné par Menhir au post #2.

Si la fonction normale ne convient pas, Pierre a donné une autre piste.

Je ne dit pas que ce n'est pas possible de le faire en vb.net, mais que dans ce cas ça n'a pas d’intérêt car :

- c'est directement faisable en vba natif
- le faire en vb.net va ajouter une touche de complexité pour le demandeur, si il ne sait pas le faire en VBA, il sera encore plus compliqué pour lui de le faire en vb.net
- proposer d'utiliser des ActiveX, solution peu à peu abandonnée alors qu'on peut faire autrement est pour moi une connerie.

[Pierre Fauconnier]

Clément,

Je pense que l'on ne met pas les solutions .net en doute. Pour ma part, je privilégie les solutions VBA parce qu'elles sont embarquées dans le fichier, et sont donc portables facilement.

Déployer une solution .net liée à un fichier Excel requiert des fichiers externes, l'installation des frameworks .net nécessaires selon la version utilisée par le développeur, et ce sur toutes les machines qui utiliseront la solution. Ces contraintes sont parfois bloquantes si le service informatique de la boite rechigne à installer tout cela. Le monde de l'excel "programmé" ne se limite pas, et de loin, à une personne qui développe dans son coin et qui a la main sur l'installation complète de sa machine. J'ai pour ma part déjà dû développer des trucs en Excel juste pour contourner le service IT qui interdisait un Access ou autre.

Proposer une solution .net n'est donc pas toujours LA solution, vu les contraintes de l'installation informatique sur laquelle ladite solution doit fonctionner.

[clementmarcotte]

Bonjour,

Clément,

Je pense que l'on ne met pas les solutions .net en doute. Pour ma part, je privilégie les solutions VBA parce qu'elles sont embarquées dans le fichier, et sont donc portables facilement.

Je n'ai jamais dit le contraire. Ok j'ai sauté sur le contrôle, parce que ma lecture de la question m'avait dirigé vers là. Mais je n'ai jamais contesté votre interprétation de la question qui vous fait dire que c'est un UserForm. Après relecture, c'est une interprétation qui se tient.

Déployer une solution .net liée à un fichier Excel requiert des fichiers externes, l'installation des frameworks .net nécessaires selon la version utilisée par le développeur, et ce sur toutes les machines qui utiliseront la solution

C'est vrai. Mais. car il y a un mais, c'est la même chose pour tous les logiciels commerciaux conçus avec la plate-forme .net. Et quelque part c'est aussi vrai avec JAVA si le vendeur du PC ne l'a pas installé. Et quand tu vois un programme d'installation débiter une série de redistribuables C++ ou VC++, il y a de grandes chances que ce soit un programme .net.

Ces contraintes sont parfois bloquantes si le service informatique de la boite rechigne à installer tout cela.

Oui mais (un autre mais), ClickOnce permet de programmer automatiquement l'installation du Framework et de d'autres programmes obligatoires. C'est la même chose que pour tout programme du commerce qui fait souvent des choses en cachette, parce que le Service de dictature informatique leur a alloué les privilèges d'administrateur. Et puis toutes les versions Community et supérieures de Visual Studio permettent l'utilisation d'extensions. Et dans ces extensions, il y en a pour créer des programmes d'installation. Là c'est au Service de dictature informatique de décider ou de justifier pourquoi il accepte un installateur venant de A et pas de B. D'autant plus que rendu là, le principe de base qui est supposé garantir la sécurité du programme c'est une signature électronique que n'importe qui peut acquérir sur Internet.

Le monde de l'excel "programmé" ne se limite pas, et de loin, à une personne qui développe dans son coin et qui a la main sur l'installation complète de sa machine. J'ai pour ma part déjà dû développer des trucs en Excel juste pour contourner le service IT qui interdisait un Access ou autre.

Oui mais (encore), souviens-toi de l'époque de mpfe quand les Services de dictature informatique installaient Excel sans installer VBA ou l'aide complète de VBA

Proposer une solution .net n'est donc pas toujours LA solution, vu les contraintes de l'installation informatique sur laquelle ladite solution doit fonctionner.

Oui mais un dernier mais. Ce sont les mêmes contraintes que pour n'importe quel logiciel commercial. Et je te laisses une question fondamentale pour tout forum. Est-ce à nous qui répondons ou aux dirigeants d'un forum, de décider qu'une solution proposée convient ou non, à la personne qui a posé la question ? Parce, en virant la question de bord, si toutes les questions qui parlent d'Excel et de gestion des données, ou Excel et YouTube ou Excel et Windows Media Player ou Excel et les fichiers wav ou Excel et la gestion d'images étaient interdites; ce forum se viderait de 50 % et plus de ses questions.

Tiens, je vais faire mon JPS et digresser un peu, en te contant une histoire vraie. Il y a quelques jours, nous avons appris qu'un employé subalterne du Mouvement des Caisses Desjardins a réussi à voler, sur une simple clef USB, les informations personnelles (sans les mots de passe heureusement) de 2,6 millions de clients. Des informations qu'il avait l'autorisation d'utiliser pour les fins de son travail. Et certaines de ces informations ont déjà été à la source d'actes criminels. (Et, à cause des enquêtes de la Police, il a fallu pratiquement six mois, pour arriver à 2,6 millions de personnes.) Donc, à la limite, un employé indélicat de Microsoft, Adobe, Corel etc. qui serait autorisé à accéder aux signatures électroniques de son employeur pourrait théoriquement programmer un routine indélicate et la faire passer pour une application officielle qui passerait toutes les mesures de sécurité, parce qu'elle serait signée par un "grand".

[Pierre Fauconnier]

Clément,

Je suis d'accord avec tout ce que tu as écris (et je te remercie d'avoir fait revivre jps du mpfe pour quelques instants.... )

Pour répondre à ta question sur "qui décide de ce qui est sur un forum", je dirai que c'est surtout la teneur de la discussion qui fait qu'une question reste à sa place ou est redirigée. Samiess ayant déserté, nous restons avec nos suppositions. Comme tu le soulignes, pas mal de questions posées sur VBA Excel n'ont aucun lien avec Excel. Soit c'est du VBA pur, soit c'est un problème lié à une librairie particulière (VBScript ou autre). Quand on tombe dessus, on déplace, mais on fait ce qu'on peut avec les moyens du bord. Je pense d'ailleurs que des questions posées sur les forums .net auraient plus leur place sur le forum Excel (rubrique à créer?) lorsqu'ils ne parlent que d'Excel.

Pour ce qui est du pilotage d'Excel par .net, nous manquons de tutos et de ressources pour qu'au final, le demandeur puisse choisir en connaissance de cause et en fonction de ce qu'il peut réaliser sur sa machine.