XL 2016 Gérer un évènement sur un grand nombre de contrôles de même type d'un UserForm

[Dudu2]

Bonjour,

J'ai 100 TextBoxes dans un UserForm.
Je voudrais gérer soit le _Enter soit le _DblClick sur tous ces contrôles pour y faire quelque chose de commun.
Pour éviter de déclarer 100 fois dans le code du UserForm le même évènement sur chacune des TextBoxes j'aimerais savoir s'il y a un autre possibilité, genre une classe dédiée.
Mais je ne suis pas très expert dans ce domaine et serais reconnaissant pour toute aide apportée sur la méthode.

Ci-joint un fichier avec 1 userForm de 3 TextBoxes comme base pour proposer un code qui ferait un simple MsgBox "Hello" sur un double-clic dans toutes les TextBoxes.
Merci par avance.

 

[Dudu2]

Non, je ne vois pas. Mon code fonctionne comme attendu, donc s'il y a des erreurs ça devrait planter, non ?

Je sais que dans mon fichier il y a une petite incohérence puisque je n'ai pas changé le Parent du UserForm à Excel.
La minimisation par le code est relative à la fenêtre Excel et la minimisation par le bouton est relative à l'écran (of course et je le sais bien). Mais c'est acceptable et s'il le faut je peux rattacher le UserForm à Excel pour être complètement cohérent.

 

[patricktoulon]

c'est pas que ca me plaît pas c'est que c'est pas fini
bon après ton code a rallonge me gène un peu mais bon c'est toi qui vois

je pars du principe que quand on propose une source il faut avoir tout passer en revue
y compris les méthodes d'imbrication et d’interdépendance des fonctions inutiles
et même là encore !! il y a des choses qui nous échappent

pour te donner une idée( et c'est véridique!!!)
mon calendar en est a sa version 4.4.2 depuis debut décembre 2021 et je ne l'ai pas distribué encore
et ben tu sais quoi un de mes beta testeurs a trouvé une faille que j'avais pas vu la semaine dernière
et on est en septembre 2022
et pourtant courant décembre 2021 deux classes à l'IUT de toulon l'ont testé et c'est des tronches les minots hein pas des rigolos
et ben..... ils ont rien vu
et c'est un pot au canada qui a trouvé et c'est un autodidacte

tu es bon et rigoureux en plus ,mais tu t’étale trop

 

[patricktoulon]

Non, je ne vois pas.
Je sais que dans mon fichier il y a une petite incohérence puisque je n'ai pas changé le Parent du UserForm à Excel.
La minimisation par le code est relative à la fenêtre Excel et la minimisation par le bouton est relative à l'écran (of course et je le sais bien). Mais c'est acceptable et s'il le faut je peux rattacher le UserForm à Excel pour être complètement cohérent.

non c'est pas ça

 

[patricktoulon]

alors
j'explique
cette petite fonction(méthode) que j'ai inventé un jour de pluie
est en general pour traiter des dimensions et position dans excel(le gridline) qui lui SEUL!! et touché par le zoom
donc
erreur N° 1
alors que toi tu traite des dimensions niveau desktop(ex: le left de l'app c'est niveau desktop) qui eux ne subissent pas le zoom c'est balloh!! en zoom sup ou inf

erreur N°2
ben c'est simple activewindow.activepane est assez explicite (la pane active de l'active window)
sauf que si tu est fractionnée ou meme ligne ou colonne figé dans ta feuille et de plus le freezpane activé et que tu est sur la panne 2 ou 3 ou 4 ben tu es chocolat
toujours utiliser activewindow.panes(1)pour avoir la mesure basic exeptant toutes les considération précédemment citées

donc la bonne méthode et celle qui suit

Function PtoPix()
    With ActiveWindow.Panes(1)
        Z = .Parent.Zoom / 100
        PtoPix = (((.PointsToScreenPixelsX(1001) - .PointsToScreenPixelsX(0)) / 1001) / Z)
    End With
End Function

Sub test()
    MsgBox PtoPix
End Sub

tu sera toujours à 1.333XXXXXX en dpi 100
ou 1.666XXXXX en dpi 120

voilà il y a quand meme quelques petites variations de 0.0000xxx pixels!! mais bon c'est du pipi de chat

 

[Dudu2]

Il y a des erreurs dans la fonction UserFormMinimizeToScreen() que je viens de corriger.
Mais elle est non utilisée dans le fichier publié.

 

[Dudu2]

Ok, je veux bien prendre le ActiveWindow.Panes(1) au lieu du ActiveWindow.ActivePane si tu le dis je te crois. Même si je ne comprends pas pourquoi le résultat du calcul serait différent sur un Pane #2 ou #3 ?!

Par contre je ne comprends rien à ton Erreur n°1 !

 

[patricktoulon]

relis le post 65

 

[patricktoulon]

d'accords
tu ne comprends pas l'erreur N°1
allez teste ces deux versions dans un fichier
une avec prise en compte du zoom et l'autre non
pour le test change bien entendu le zoom pour un zoom différent de 100

Function PtoPix()
    With ActiveWindow.Panes(1)
        Z = .Parent.Zoom / 100
        PtoPix = (((.PointsToScreenPixelsX(1001) - .PointsToScreenPixelsX(0)) / 1001) / Z)
    End With
End Function
Function PtoPix2()
   'ici on prends pas le zoom en compte
   With ActiveWindow.Panes(1)
        PtoPix2 = ((.PointsToScreenPixelsX(1001) - .PointsToScreenPixelsX(0)) / 1001)
    End With
End Function

Sub test()
    MsgBox PtoPix
End Sub

Sub test2()
    MsgBox PtoPix2
End Sub

tu veux une démo avec l'erreur N°2 aussi ?

 

[Dudu2]

Donc c'est pas le Pane qui fait la différente mais le Zoom.
Ce système de PixelToPoint sans API je l'ai copié il y a un certain temps dans un de tes modules.
Donc si c'est faux, je retourne aux basics de l'API pour déterminer le PixelToPoint.

A noter que ce PixelToPoint n'est pas utilisé dans le fichier actuel.
Mais je vais quand même le corriger.

 

[patricktoulon]

si si les deux erreurs sont importantes la 2 en cas de fractionnement ou fgés sur la feuille

Ce système de PixelToPoint sans API je l'ai copié il y a un certain temps dans un de tes modules.

et oui mais il fallait analyser le reste du code pour voir que je le fait plus loin sur le global
c'est ça le truc qu'il faut comprendre
sur des dimension feuille à feuille ca passe mais de dimension feuille à desktop ben là bien sur

revenir au basic api et allez une 10 eme api getdevicap
tu n'a pas l'impression que ca va vraiment devenir lourdingue là serieux ????

 

[Dudu2]

L'erreur n° 2 est purement fictive.

 

[Dudu2]

Dans le calcul du PixelToPoint il manquait l'intégration du Zoom. Ok, parfait tu avais raison !
Mais tu te rends compte de tout le tintouin que tu me fais pour ça au lieu d'aller directement au but ?

A ce niveau, c'est plus des paraboles, c'est la comedia del arte !

 

[Dudu2]

Est-ce que tu saurais pourquoi quand le UserForm est rattaché à Excel son style est:

Et quand il ne l'est pas son style est:

 

[patricktoulon]

et non c'est pas de la comédie
c'est faux c'est tout
dranreb , Rollan M et moi avons chacun travaillé sur une version différente pour le pixeltopoints et vice et versa pour les userform et on a bien galérer avec pointstoscreenpixels
aujourd'hui tu en bénéficie de tout ce temps passé a chercher
donc si je te dis que c'est important tu peux me croire
car la fonction pointstoscreenpixels est assez particulière
j'avais fait un petit tuto d'ailleurs je l'ai jamais publié

Est-ce que tu saurais pourquoi quand le UserForm est rattaché à Excel son style est: different

oui je sais
c'est par ce que à la base la fenetre userform est enfant du desktop et donc la shell et user32 prennent en charge le sysmenu de la fenetre qui en fait est vide (d'ailleurs dans ton éditeur de macro ton userform a le même style que celui quand il est enfant de l'application)
a partir du moment ou tu change cet ordre hiérarchique il faut demander la le dwm.dll de remettre le style arero de W10 (donc blanc) ou transparent de win 7

 

[Dudu2]

Sinon pour info, j'ai trouvé un moyen de détecter a posteriori si le UserForm est rattaché à Excel:

UsfParentIsExcel = (GetNextWindow(Usf.UsfHandle, GW_HWNDPREV) = 0)

Je sais pas trop ce que ça fait et si c'est toujours juste, mais jusque là ça fonctionne.