XL 2016 VBA - Origine d'un évènement

Dudu2

XLDnaute Barbatruc
Bonjour,
Peut-on savoir si un évènement (Worksheet_Activate() par exemple) est généré par un code VBA ou une activation manuelle par un utilisateur ?
Merci
 

Dranreb

XLDnaute Barbatruc
Bonjour.
Non, mais on peut positionner une variable globale Boolean à True avant d'activer la feuille par du code pour pouvoir l'y tester.
Si le but est que la procédure sois sans effet dans ce cas on peut aussi désactiver la prise en charge des évènements Excel par Application.EnableEvents = False devant. Ne pas oublier de désactiver le dispositif derrière l'activation programmée en remettant la variable globale à False ou Application.EnableEvents à True. Mais si ce n'est pas à l'intention de l'utilisateur, le mieux c'est encore de ne pas activer du tout de feuille.
 

patricktoulon

XLDnaute Barbatruc
Bonjour @Dudu2
pour moi non
mais je suppose que si tu cherche bien tu trouvera quelque chose mais a un prix avec un code a dormir debout

en tout cas un tel besoin signifie pour moi un manque de réflexion dans la conception du programme au départ

sub test()
'faire ceci 'activation du sheet🥳
'heu pourquoi je voulais faire ça déjà🤔
'qui a fait ca non de dieu!!!:mad:
end sub
🤪

utilise une variable flag le cas échéant
module
VB:
Public flagsheetActive
Sub test()
flagsheetActive = 1
Feuil2.Activate
End Sub

dans le Thisworkbook
Code:
Private Sub Workbook_SheetActivate(ByVal Sh As Object)
    If flagsheetActive = 1 Then
        MsgBox "activer par vba"
    Else
        MsgBox "activé manuellement"
    End If
    flagsheetActive = 0
End Sub
 

Dudu2

XLDnaute Barbatruc
Bonjour @Dranreb, @patricktoulon,

Je me doutais bien qu'il n'y a pas moyen de différencier et je vous remercie pour vos confirmations.

Si j'exclue le manque de réflexion dans la conception du programme au départ, (merci quand même) c'est qu'il y a un contexte particulier.

Un Complément positionne un petit UserForm en bas de feuille, sur la zone Status Bar.
Ce petit UserForm, dans un environnement Comptable a de multiples fonctions très utiles (somme et différence de sélection, nombre de cellules numériques, etc...) et il a besoin de s'adapter sur des Activate/DeActivate/Resize/Selection_Change/DblClick de feuille et fenêtre faits par l'utilisateur. Une classe de gestion d'évènements s'en charge dans le Complément.

Lorsqu'un classeur de macros indépendant doit faire des manips sur des classeurs et feuilles, évidemment que tout ça n'a plus de sens. Il y a donc tout lieu d'activer/désactiver un flag dans le complément via une fonction appelée sur un OnKey xyz par exemple, et d'envoyer par SendKeys ce xyz dans le classeur de macros.

Sinon un autre moyen de communiquer entre un classeur de macros et un complément dont le nom change avec les versions ?
 
Dernière édition:

Dudu2

XLDnaute Barbatruc
Même si je pense que ce n'est pas ou très peu utilisé, la fonctionnalité prévoit d'afficher les infos soit dans le UserForm soit dans la Status Bar soit les 2.

De plus je dois gérer des évènements sans rapport avec ce UserForm (App_WorkbookActivate / App_WindowActivate) pour gérer les bugs / problèmes avec les classeurs vierges ou les classeurs identifiés par toute ou partie de leur nom ou comme "non-candidats" au UserForm.
Aussi par exemple App_SheetBeforeDoubleClick() qui si un UserForm de recherche est affiché, appelle une fonction de ce UserForm.

Donc les évènements ne sont pas exclusivement dédiés au petit UserForm.

Pourquoi penses-tu qu'il est préférable que ce soit dans le UserForm ?
 

patricktoulon

XLDnaute Barbatruc
re
Sauf que je n'arrive pas à communiquer entre le classeur de macros et le Complément, sachant que je ne connais pas le nom du Complément. Mon système de SendKeys ça ne marche pas !
C'est bon, on peut appeler les fonctions d'un Complément directement avec Application.Run sans même citer le nom du Complément.
je te l'ai expliqué plusieurs fois que c’était possible et surtout sans application.run
mais tu persiste dans le bricolage avec des pirouettes vbaistique
je ne vais pas perdre mon temps une énième fois à te l'expliquer
c'est le B à Ba des modules classe quel qu'il soit d'ailleurs
tout les un ans à peu près tu reviens sur ce problème (qui n'en est qu'un que pour toi)
et là mes mots doivent te titiller à l'oreille et peut être te rappeler une discussion 2021 ou 2022 ou 2023 et oui perso j'ai une excellente mémoire
peut être que @Dranreb aura les mots pour te le faire comprendre
 
Dernière édition:

patricktoulon

XLDnaute Barbatruc
S'il a un nom de projet différent de VBAProject et de celui du classeur de macros, il peut être coché dans les références du projet du classeur de macros. Tout ce qui est public dans le complément y est alors connu.
je lui ai expliqué ça il y a des années il a toujours prétendu que ce n’était pas orthodoxe d'utiliser les classes comme ça
parce que (et là je le cite en 2022) "ce n'est pas dans l'aide de Microsoft "

je parirais a 10 contre 1 que le vbaproject de ces classes n'ont pas de nom
d'ailleurs vu comment il s'en sert il n'en a pas besoins

on est en 2024
;)
 

Discussions similaires

Statistiques des forums

Discussions
314 633
Messages
2 111 418
Membres
111 127
dernier inscrit
flygreg