Coup de pouce
bonjour a tous
une nouvelle fois j'ai besoin de vos lumières............
j'ai créée il a fort longtemps un useform qui me permettait d'effectuer une recherche selon plusieurs critères
j'essai aujourd'hui de réutiliser cela sur un autre fichier mais il y a un bug ou plutôt deux que je ne comprends pas
voici le code utilisé:
Private Sub CommandButton22_Click()
UserForm3.Show
End Sub
Private Sub T1_Change()
Dim i&, fin&, Y&, a&, aa, bb, lig&, col&
Application.ScreenUpdating = 0
If T1 = "" Then L1.Clear: Exit Sub
L1.Clear
With Feuil1
Y = 1
fin = .Range("A" & Rows.Count).End(xlUp).Row
col = .Cells(1, Columns.Count).End(xlToLeft).Column + 2
If fin < 2 Then fin = 2: Exit Sub
aa = .Range(.Cells(2, 1), .Cells(fin, col))
End With
For i = 1 To UBound(aa)
aa(i, UBound(aa, 2) - 1) = i + 1
aa(i, UBound(aa, 2)) = ""
Next i
For i = 1 To UBound(aa)
For a = 1 To UBound(aa, 2)
If aa(i, a) Like "*" & T1 & "*" Then aa(i, UBound(aa, 2)) = "oui": Y = Y + 1: Exit For
Next a
Next i
If Y = 1 Then Exit Sub
ReDim bb(Y - 1, UBound(aa, 2) - 1)
Y = 1
For i = 1 To UBound(aa)
If aa(i, UBound(aa, 2)) = "oui" Then
For a = 1 To UBound(aa, 2) - 1
bb(Y, a) = aa(i, a)
Next a
Y = Y + 1
End If
Next i
With L1
.ColumnCount = UBound(aa, 2) - 2
.List = bb
End With
End Sub
Private Sub UserForm_Click()
End Sub
End Sub
Private Sub CommandButton23_Click()
End Sub
a l'origine ce useform permettait soit de faire une recherche en tapant dans le volet de recherche, soit d'effectuer une recherche globale
je joint en PJ une vue du useform pour une meilleure compréhension
si quelqu'un a une idée je suis vraiment preneur
PS . Je suis presque certain qu'il y a une énormité qu'avec vos connaissances vous saurez détecter
merci à tous
charly
Bonjour
titre peu explicite, cela va limiter les recherches futures !
si j'avais su qu'il s'agissait de userform je n'aurai pas lu le post
Bonjour,
C'est une blague !
C'est vrai qu'un fichier Word est très utile dans un forum dédié à Excel !
bonjour
salut Theze, le forum porte le nom d'Excel certes, mais cette section du forum c'est
Excel - VBA
regarde en haut de ton écran
dès lors, quelle est la signification du tiret ? ET ou bien OU
car VBA n'est pas ce qu'on pense habituellement, A signifie Applications, c'est à dire tout Office et aussi d'autres logiciels, une dizaine env.
il n'est nullement destiné à Excel exclusivement.
alors toute question VBA me semble la bienvenue ici.
même si les spécialistes VBA pour Word seront peu nombreux, un VBAiste est un VBAiste.
laissons la liberté !
déjà que moi je demande qu'on puisse mettre en PJ des .pbix
bon dimanche à tous
amitiés excelliennes et officiennes
Bonjour à tous,
car VBA n'est pas ce qu'on pense habituellement, A signifie Applications, c'est à dire tout Office et aussi d'autres logiciels, une dizaine env.
il n'est nullement destiné à Excel exclusivement.
Il y a certes des façons de faire pour que ça marche, pour pouvoir manipuler des éléments Word à partir d'Excel, mais je vais devoir écrire un autre code parce que je me trouve dans Excel et pas dans Word...
Alors dans VBA, le A ne signifie pas que l'on travaille dans toutes les applications Office + quelques autres, mais que VBA est un outil de programmation dédié, qui ne peut fonctionner hors d'une application, ce qui n'est pas tout à fait la même chose.
Et à chaque application son VBA, qui comporte une part commune à tous, appuyée sur le langage Visual Basic, mais une part propre à l'application à laquelle il est couplé. Par rapport à VB, VBA représente une contrainte car lié à une application, et non autonome, mais simultanément une facilité d'emploi dans l'application car on y est dispensé de créer les instances d'objets de l'application que l'on va utiliser...
Par conséquent on doit interpréter que dans Excel-VBA on a affaire à Excel et au VBA d'Excel !
@Charly : Tu devrais commencer par mettre ton code sous balise Code, cela rend le code plus facile à lire, et cela conserve l'indentation. Ne pas le faire me paraît dénoter un certain mépris vis-à-vis des intervenants, que pour ma part je n'apprécie guère.
Ensuite si ton code n'est pas indenté, je t'engage à l'indenter, et tu pourras constater que tu lis plus vite un code indenté qu'un code qui ne l'est pas...
Enfin, quand on on soumet une erreur, on précise la nature de l'erreur, le numéro d'erreur s'il s'agit d'une erreur d'exécution, la ligne sur laquelle se produit l'erreur, et si on veut vraiment bien faire les valeurs des variables au moment de l'erreur assorties d'une description plus étoffée du contexte dans lequel elle s'est produite.
Si cela ne suffit pas, il faudra alors fournir un fichier permettant de constater l'erreur et l'analyser de plus près...
Cordialement.
Bonjour à tous,
car VBA n'est pas ce qu'on pense habituellement, A signifie Applications, c'est à dire tout Office et aussi d'autres logiciels, une dizaine env.
il n'est nullement destiné à Excel exclusivement.
A c'est bien Applications... Cependant si j'ouvre Excel, accède à VBA, y place une procédure conçue pour Word, ça ne va pas fonctionner !... parce que mon VBA ne va pas trouver dans la bibliothèque d'Excel les composants sur lesquels le code intervient. Il y a certes des façons de faire pour que ça marche, pour pouvoir manipuler des éléments Word à partir d'Excel, mais je vais devoir écrire un autre code parce que je me trouve dans Excel et pas dans Word...
ai-je dit le contraire ?
mais par exemple sur un forum C++ on trouve aussi des spécialistes de gestion de données ou d'Android, ou de etc.
ils n'ont pas besoin des mêmes fonctions, et pourtant ils discutent sur les mêmes forums un peu généralistes, ou très spécialisés. Ils sont libres
je plaide pour une telle liberté, malgré mon aversion que tu connais bien pour VBA !
car enfin, comment faire de belles applis si on ne peut, par exemple, marier Excel avec Word, ou Outlook ?
ou faire du Word seul
toute question VBA, avec ou sans Excel, est bonne pour VBA !
(je n'avais jamais pensé écrire un truc pareil, en faveur des discussions sur VBA ! ah, quand on est pour la liberté, on en fait des bêtises
bon dimanche
amitiés excelliennes
Re-BonFour jmd, Mferrand
Avec un titre pareil, nul de chez nul, on va continuer à disserter ...
- je hais word, le pire logiciel de traitement de texte, brouillon dans ses mises en forme (il suffit de voir les exportation html !!)
- outlook : je ne l'utilise qu'au travail, il a remplacé lotus, (mais perso je préfère Thunderbird et Google avec de beaux scripts sous drive): il y a peu de sites sur le VBA d'outlook, j'ai pu y goûter, c'est très intéressant et j'ai pu développer des applications d'export vers excel notamment pour rappeler les plannings de formation du personnel
VBA est le même pour tous, mais c'est la structure des objets qui est différente. Autre différence : la macro suit le fichier excel dans 95% des cas, jamais avec un email (la macro doit être enregistrée sur le poste de travail)
Bonjour à tous
- je hais word, le pire logiciel de traitement de texte, brouillon dans ses mises en forme (il suffit de voir les exportation html !!)
Puisqu'on est sur un forum universel et comme c'est dimanche, je répond sur ce point : les exportations html sont effectivement du grand n'importe quoi mais cela est du au fait que MS a toujours bricolé dans ce domaine (même son logiciel de création de sites faisait un HTML pourri) mais Word, si on utilise correctement les styles (qu'on peut paramétrer) n'est pas brouillon du tout même si certaines possibilités se sont dégradées au fil des versions.
Trop d'utilisateurs utilisent leur traitement de texte comme la machine à écrire de ma grand-mère...
Chacun est libre de discuter sur n'importe quel Forum !
Mais cela ne doit pas empêcher de reconnaître que ce Forum Excel-VBA est consacré à Excel et son VBA, ce qui pourra inclure naturellement des sujets passerelles vers d'autres applications, cependant à partir d'Excel. Et je n'entends nullement contrevenir à la liberté d'un demandeur d'être hors sujet le cas échéant.
Mais en fait ici, il s'agissait de la fourniture d'un fichier Word, non destiné par ailleurs à illustrer une connexion entre Excel et Word, mais pour fournir une image incluse, destinée à illustrer une procédure incontestablement Excel. Faire remarquer qu'il y avait là une série d'inadéquations était pleinement légitime !
Et cela n'ôte de liberté à personne !
Au demeurant, ton aversion pour VBA, que ton post ne remet pas en cause, me surprend toujours un peu, dans la mesure où si je peux être d'accord quand il s'agit d'utilisations inadéquates de VBA ou qui n'apportent strictement rien, dans de nombreux cas j'y vois une aversion anti-automatismes qui m'apparaît passéiste.
En effet, il est pourtant bien naturel que quelqu'un qui peut accomplir facilement des opérations avec notamment les outils que tu promeus, lorsqu'il doit répéter ces actions, trouvera un confort certain à les faire lancer par VBA, au moyen d'un bouton ou d'un raccourci clavier, ou à partir d'un évènement. VBA ne fera rien d'autre que ce qu'il faisait, utiliser Excel ! Et je ne vois aucune opposition entre Excel et VBA !
VBA ne fait rien d'autre qu'utiliser Excel, en y ajoutant les possibilités que permet la programmation de le faire parfois selon des modalités que l'on ne pourrait mettre en oeuvre manuellement.
Le cas le plus simple en la matière est l'opération de copier-coller, opération tout à fait élémentaire, bien qu'elle ne soit pas toujours clairement identifiée par les utilisateurs qui l'utilisent souvent de façon générique pour tout ce qui consiste à faire apparaître un contenu ailleurs qu'à sa position initiale, y compris par formules...
Le copier-coller fait transiter un contenu par le presse-papier de Windows, on y copie généralement tous les éléments de ce contenu et au collage on peut choisir diverses options de restitution... On peut le faire avec VBA, qui fera alors ce que fait Excel lorsqu'on le fait manuellement, c'est parfois plus économique mais dans de nombreux cas où l'on n'a besoin à l'arrivée que des valeurs, VBA peut faire autrement que transiter par le presse-papier, donc sans copier-coller, opération plus rapide qu'un copier-coller. Pourquoi ne pas le faire alors ?
La conjonction Excel-VBA apporte une amélioration dans une opération simple.
Autre cas qui montre la synergie que l'on peut tirer de la coopération Excel-VBA : la possibilité pour VBA de recourir aux fonctions Excel... Il y a trop souvent des demandeurs qui s'amusent à coder l'insertion de formules par VBA dans des cas standards de mises en place de formules qui n'auront plus à bouger par la suite, ce que je considère comme un amusement idiot (mais je n'empêche personne de s'amuser à ça
Mais l'utilisation des fonctions Excel apporte, elle, un plus à VBA lorsqu'il s'agit de fonctions inexistantes en VBA.
VBA permet d'utiliser des tableaux, ce qui lui permet certaines opérations très rapides dès lors qu'on peut utiliser cette méthode, mais dispose de peu de fonctions pour agir dans ses tableaux, lesquels doivent alors être alimentés élément par élément au moyen de boucles.
Prenons le cas où l'on récupère des lignes d'un tableau sous condition, on dispose de divers moyens pour cerner ces lignes dans Excel et les transférer... On le fera efficacement en VBA en transitant par un tableau, mais il faudrait alors affecter la valeur de chaque cellule de la ligne à un élément du tableau, même si c'est rapide ce sera un peu plus long que prélever la ligne... et c'est là que VBA qui ne peut le faire nativement va pouvoir en utilisant Index, fonction d'Excel, pour prélever une ligne globalement et l'affecter à un tableau. Plus, pouvant alors prélever la ligne (soit un tableau), il n'a plus besoin que d'un tableau unidimensionnel (au lieu de bidimensionnel), pour l'affecter transitoirement. On utilise là une méthode créant une véritable synergie entre VBA et Excel.
Il y a aussi quelques cas où VBA fait gagner du temps sur l'utilisation manuelle de fonctionnalités Excel. L'exemple que je cite souvent est le filtre avancé. Faire un filtrage avancé manuellement est une galère : on a un assistant, on sert des rubriques... Dès lors qu'on maîtrise un peu l'opération, écrire la macro (la commande de filtrage y tient en une ligne de code) et l'exécuter sera plus rapidement accompli que le faire en utilisant l'assistant.
VBA ne peut se dissocier de l'application à laquelle il est attaché. Et on ne pourra l'utiliser correctement ni efficacement sans une bonne connaissance du fonctionnement de l'application. Et le plus souvent on ne fera bien en VBA que ce qu'on est capable de faire dans Excel sans VBA.
En espérant ne pas m'être épanché trop longuement...
Bonjour à toutes et tous,
Quand j'ai dis :
C'est une blague !
C'est vrai qu'un fichier Word est très utile dans un forum dédié à Excel !
je ne visais que le fichier joint en .docx et non le fait que la question porte sur l'automatisation d'une autre application qu'Excel depuis Excel !
Comment peut-on tester un fichier à partir d'un image ?
merci a tous pour vos réponses
Pour le fichier c'est juste une copie écran d'un fichier Excel ...........rien de plus !!!
Bonjour Charly,
J'ai bien compris que c'est une copie d'écran mais le mieux est de poster ton classeur car ceci nous évite de devoir construire un formulaire pour tester !
re à tous
MFerrand,
j'ai lu ton long message en faveur de VBA (et aussi pour la liberté sur le forum)
il me semble que les exemples d''applications de VBA que tu cites n'aient aucun besoin de macro. Excel possède toutes les fonctions nécessaires.
peut-être pourrions-nous ouvrir une discussion du genre "et celle-là, tu sais la faire sans VBA ? "
je suis sérieux
ça permettrait donc à chacun sur le forum de voir les avantages et limites avec ou sans VBA. Et ce serait plus constructif.
amitiés excelliennes à tous