XL 2013 Lignes de résultats surnuméraires dans une ListBox

Dranreb à dit:

Un conseil: n'utilisez jamais de Multipage.

Cliquez pour agrandir...

J'avais bien noté dans un de vos messages précédents que c'était une option qui n'avait pas vos faveurs !
Je trouve la chose plus élégante que d'avoir plusieurs formulaires de recherche indépendants, mais si c'est incontournable je vais devoir à nouveau revoir sacrément ma copie.

Têtu je suis.

Pendant que j'étais dans les bouchons, j'entrevois une solution simplissime à mon problème : ne déclencher les CLs.Add et CLs_SujFltChg, que lors du changement de page du MultiPage avec un tout bête "If MultiPage1.Value = X Then ...".

J'entreprends les ajouts et connections de ce énième tuyau dans mon usine à gaz il y a quelques minutes et... Roulement de tambour...
Page 1, j'ai les bon items, j'en sélectionne un, la ListBox est mise à jour. Pas d'erreur 9. Bon.
Page 2, j'ai les bon items, j'en sélectionne un, la ListBox est mise à jour. Pas d'erreur 9. Bien.
Page 3, j'ai les bon items, j'en sélectionne un, la ListBox est mise à jour. Pas d'erreur 9. Oh yeah !

A ce stade j'envisage de passer à autre chose avec le doux sentiment d'une victoire sur l'implacable machine.
Par acquis de conscience néanmoins, je reviens sur la page 1 et là, patatras, mon beau château tout neuf est en un instant réduit à néant : Erreur 9 et un beau surlignage de "Parent.CBM_Change Me".

Je reproduis l'expérience dans un ordre différent : erreur d’exécution 13, incompatibilité de type.
Nouveau test dans le désordre : erreur 9 sur "ReDim Preserve LesClés(0 To LR), LesListes(0 To LR)".

Donc telles que je vois les choses, il me faut un moyen de détruire à chaque changement de page les ComboxBoxs Liées existantes.
Je pourrais sans doute les créer et détruire dynamiquement, c'est déjà ainsi que je pratique pour ma navigation, mais dans le cas du formulaire de recherche cela implique une vingtaine de ComboBoxs à produire et positionner et, pour tout dire, ça me gave un tantinet.

Auriez-vous une suggestion sur la manière de juste renvoyer dans les limbes les occurrences devenues encombrantes de ComboBox Liées ?

Il faut en utiliser 3 différents, avec des noms différents CLsA, CLsB et CLsC par exemple, les initialiser touts dans la Sub UserForm_Initialize mais à chaque fois terminer par CLsA.Stopper. Au changement de page CLsA.Réactiver, après avoir stoppé l'éventuel autre CLsX actif

Dranreb à dit:

Il faut en utiliser 3 différents, avec des noms différents CLsA, CLsB et CLsC par exemple, les initialiser touts dans la Sub UserForm_Initialize mais à chaque fois terminer par CLsA.Stopper. Au changement de page CLsA.Réactiver, après avoir stoppé l'éventuel autre CLsX actif

Cliquez pour agrandir...

Une fois de plus, un grand merci Dranreb, je tente ça de ce pas !

Je me demande quand même s'il ne vaudrait pas mieux que les artisans soient dans une base différente, avec des colonnes différentes, s'il y a tellement de différences que vous devez les traiter dans des pages différentes. Il me semble aussi que dans ce cas il devrait y avoir nombre de colonnes qui ne servent à rien, selon que c'est un artisan ou pas …

Dranreb à dit:

Il faut en utiliser 3 différents, avec des noms différents CLsA, CLsB et CLsC par exemple, les initialiser touts dans la Sub UserForm_Initialize mais à chaque fois terminer par CLsA.Stopper. Au changement de page CLsA.Réactiver, après avoir stoppé l'éventuel autre CLsX actif

Cliquez pour agrandir...

Dranreb à dit:

Je me demande quand même s'il ne vaudrait pas mieux que les artisans soient dans une base différente, avec des colonnes différentes, s'il y a tellement de différences que vous devez les traiter dans des pages différentes. Il me semble aussi que dans ce cas il devrait y avoir nombre de colonnes qui ne servent à rien, selon que c'est un artisan ou pas …

Cliquez pour agrandir...

C'est une question qui s'est effectivement posée, il est vrai que seule une moitié des colonnes de la table finale est réellement utilisée par ces items, et pendant un temps il y a bien eu deux tables séparées. J'avais changé mon fusil d'épaule pour une raison qui m'échappe sur l'instant mais qui à l'époque me paraissait fort pertinente !

Pour ce qui est de donner un nom différent à mes instances de Combox Liées, j'ai nommé selon votre exemple et j'obtiens une erreur de variable non définie dès la ligne Set CLsA = New ComboBoxLiées

Devrais-je déclarer l'instanciation différemment ?

Il doit y avoir en tête une déclaration Private WithEvents CLsA As ComboBoxLiées pour chacune, bien évidemment.

Dranreb à dit:

Il doit y avoir en tête une déclaration Private WithEvents CLsA As ComboBoxLiées pour chacune, bien évidemment.

Cliquez pour agrandir...

Mais que je suis... Merci 🙏

Cela sort un peu du topic mais comme la question me vient conséquemment à la multiplication des fonctions pour chacune des instances des ComboBox Liées je me permets de vous la poser : à votre connaissance, y a t'il un moyen en VBA d'avoir un nom de fonction qui soit dynamique ?
Dans le cas présent quelque chose du genre Private Sub CLs(variable)_Résultat(Lignes() As Long) ?

Il devrait être possible de définir un Private TCls(1 To 3) As New ComboBoxLiées, mais on ne pourrait utiliser les évènements de chaque élément qu'à travers une Private WithEvents CLs As ComboBoxLiées. Pour changer d'objet actif utiliser une séquence :

Dranreb à dit:

Il devrait être possible de définir un Private TCls(1 To 3) As New ComboBoxLiées, mais on ne pourrait utiliser les évènements de chaque élément qu'à travers une Private WithEvents CLs As ComboBoxLiées. Pour changer d'objet actif utiliser une séquence :

VB:

Private Sub ChgCLs(Byval N° As Integer)
   If Not CLs Is Nothing Then CLs.Stopper
   Set CLs = TCLs(N°)
   CLs.Réactiver
   End Sub

Cliquez pour agrandir...

Merci, je tente ça demain ! J'en étais à regarder comment faire une macro qui crée une macro...

Bonjour Dranreb,

Je continue d'avancer sur mon projet perso mais beaucoup plus lentement car le temps disponible se fait rare depuis 10 jours.

Ma question du vendredi sur vos ComboBoxLiées est relative à un problème de compilation :

j'ai le message d'erreur "Type défini par l'utilisateur non défini" dans le module de classe ComboBoxLiées lorsque j'exécute la commande "Compiler VBA project", mais sans indication sur la ou les lignes impliquées. Auriez-vous une expérience de ce problème ?

Je suis tombé sur cette difficulté en essayant de créer un EXE à partir de mon classeur, avec l'application "DoneEx VBA Compiler". Cette dernière m'indiquant au moment de la compilation en C, une erreur de syntaxe dans le module ComboBoxLiées sans elle non plus me préciser où, c'est ce qui m'a incité à faire un test de débogage (que ce mot est laid) sous Excel.

Je ne pense pas que cela puisse avoir une quelconque incidence dans le cas présent, mais pour information car au départ de ce topic je l'ai placé dans Excel 2013, je précise que j'ai depuis migré sur Office 2024 et que je suis en 64 bits.

Bonsoir.
En principe pour cette erreur le type non défini en question est surligné dans le code.
Pourriez vous joindre le classeur ?

Dranreb à dit:

Bonsoir.
En principe pour cette erreur le type non défini en question est surligné dans le code.
Pourriez vous joindre le classeur ?

Cliquez pour agrandir...

Autant pour moi : en essayant de reproduire le problème avant de vous le transmettre je me suis rendu compte que c'est en cherchant l'erreur de syntaxe relevée par le compilateur C de DoneEx VBA Compiler dans ComboBoxLiées que j'ai moi-même créé le problème de Type non défini.

Me voilà donc avec encore moins d'indice pour trouver l'erreur de syntaxe. Il faudrait que je trouve une autre application de ce type pour voir si le même problème survient. Ce n'était qu'un test puisque j'ai encore quelques améliorations à réaliser avant de libérer la bêta, mais j'avoue que j'aimerais assez trouver une solution fonctionnelle pour transformer mon classeur final en un exécutable.