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
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.
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!!!
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
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 ?
Un objet Private WithEvents App As Application en tête de l'UserForm peut être arrêté simplement par Set App = Nothing et redémarré tout aussi simplement par Set App = Application
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 ?
Faudrait que je revoie beaucoup trop de choses pour localiser l'App dans le UserForm.
Sinon, ça fonctionne très bien l'App à Nothing en ON/OFF. Pas besoin de flag.
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 !
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.
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 !
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
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