Bonjour, j'utilise une macro comme biblioth=E8que de fonction/sub et
j'en passe. Mon soucis est que toutes les proc=E9dures Public que j'ai
d=E9clar=E9es sont accessibles dans Excel dans les formules
personnalis=E9es. Est-il possible de laisser les sub/function en Public
mais de les rendre inaccessibles dans les formules personnalis=E9es ?
Bonjour, j'utilise une macro comme bibliothèque de fonction/sub et j'en passe. Mon soucis est que toutes les procédures Public que j'ai déclarées sont accessibles dans Excel dans les formules personnalisées. Est-il possible de laisser les sub/function en Public mais de les rendre inaccessibles dans les formules personnalisées ?
Merci d'avance.
JohnFuss.
Bonjour John,
tout en haut:
Option Private Module
--
lSteph
On 21 oct, 14:19, Jérôme MOUCHAIN <jmou...@gmail.com> wrote:
Bonjour, j'utilise une macro comme bibliothèque de fonction/sub et
j'en passe. Mon soucis est que toutes les procédures Public que j'ai
déclarées sont accessibles dans Excel dans les formules
personnalisées. Est-il possible de laisser les sub/function en Public
mais de les rendre inaccessibles dans les formules personnalisées ?
Bonjour, j'utilise une macro comme bibliothèque de fonction/sub et j'en passe. Mon soucis est que toutes les procédures Public que j'ai déclarées sont accessibles dans Excel dans les formules personnalisées. Est-il possible de laisser les sub/function en Public mais de les rendre inaccessibles dans les formules personnalisées ?
Merci d'avance.
JohnFuss.
Jérôme MOUCHAIN
Merci pour ta reponse, je connais (et utilise) ce Option Private Module mais mes macros qui référencent ma macro principale ont besoin d'accéder à ces sub/function...
John.
Merci pour ta reponse, je connais (et utilise) ce Option Private
Module mais mes macros qui référencent ma macro principale ont besoin
d'accéder à ces sub/function...
Merci pour ta reponse, je connais (et utilise) ce Option Private Module mais mes macros qui référencent ma macro principale ont besoin d'accéder à ces sub/function...
John.
LSteph
Avec option private module ta fonction n'apparaîtra pas dans la liste mais demeure utilisable!
On 21 oct, 15:03, Jérôme MOUCHAIN wrote:
Merci pour ta reponse, je connais (et utilise) ce Option Private Module mais mes macros qui référencent ma macro principale ont besoin d'accéder à ces sub/function...
John.
Avec option private module ta fonction n'apparaîtra pas dans la liste
mais demeure utilisable!
On 21 oct, 15:03, Jérôme MOUCHAIN <jmou...@gmail.com> wrote:
Merci pour ta reponse, je connais (et utilise) ce Option Private
Module mais mes macros qui référencent ma macro principale ont besoin
d'accéder à ces sub/function...
Avec option private module ta fonction n'apparaîtra pas dans la liste mais demeure utilisable!
On 21 oct, 15:03, Jérôme MOUCHAIN wrote:
Merci pour ta reponse, je connais (et utilise) ce Option Private Module mais mes macros qui référencent ma macro principale ont besoin d'accéder à ces sub/function...
John.
Jérôme MOUCHAIN
Je viens de tester, les modules en Option Private Module ne sont pas accessibles pour les macros qui font une référence à la macro qui contient le module.
Merci quand même.
JohnFuss.
Je viens de tester, les modules en Option Private Module ne sont pas
accessibles pour les macros qui font une référence à la macro qui
contient le module.
Je viens de tester, les modules en Option Private Module ne sont pas accessibles pour les macros qui font une référence à la macro qui contient le module.
Merci quand même.
JohnFuss.
LSteph
Bonjour Jérôme,
Désolé, mais cela marche très bien ainsi (et lis bien la suite pour ref à autre)!
'Module2 Option Private Module Public Function dilHeur() dilHeur = Format(Now, "hh:mm") End Function
'Moduel1 Sub test() MsgBox dilHeur End Sub
Et elle est même utilisable dans la feuille et n'apparaît pas dans la liste, selon ta prime demande. Après , si ton but est d'utiliser des fonctions VBA qui sont utilisées uniquement dans le code comment y fais-tu appel? On irait que tu parles de ref ou Declare comme si c'étaient des dll Je ne vois pas où se pose ton pb, tu n'es pas du tout obligé de t'y prendre ainsi! Si tu as déjà dans un autre projet un module qui contient ces fonctions, exporte le depuis celui-là ex monmodule.bas et rapatrie le dans ton projet, ca fonctionnera comme indiqué plus haut en exemple!
Amha le plus simple, et n'est toujours pas visible dans la liste des fonctions!
Maintenant si tu veux qd même réfèrer plutôt à un autreclasseur Exemple: '''''premier classeur module standard Sub autretest() Dim mtxt As String mtxt = Application.Run("autreclasseur.xls!aussilheur") MsgBox mtxt End Sub
''''autreclasseur module standard
Option Private Module Public Function AussilHeur() AussilHeur = Format(Now, "hh:mm") End Function
'Ca marche aussi!
'lSteph
Cordialement.
-- lSteph
On 22 oct, 09:17, Jérôme MOUCHAIN wrote:
Je viens de tester, les modules en Option Private Module ne sont pas accessibles pour les macros qui font une référence à la macro qui contient le module.
Merci quand même.
JohnFuss.
Bonjour Jérôme,
Désolé, mais cela marche très bien ainsi (et lis bien la suite pour
ref à autre)!
'Module2
Option Private Module
Public Function dilHeur()
dilHeur = Format(Now, "hh:mm")
End Function
'Moduel1
Sub test()
MsgBox dilHeur
End Sub
Et elle est même utilisable dans la feuille et n'apparaît pas dans la
liste, selon ta prime demande.
Après , si ton but est d'utiliser des fonctions VBA qui sont utilisées
uniquement dans le code
comment y fais-tu appel? On irait que tu parles de ref ou Declare
comme si c'étaient des dll
Je ne vois pas où se pose ton pb, tu n'es pas du tout obligé de t'y
prendre ainsi!
Si tu as déjà dans un autre projet un module qui contient ces
fonctions, exporte le depuis celui-là ex monmodule.bas
et rapatrie le dans ton projet, ca fonctionnera comme indiqué plus
haut en exemple!
Amha le plus simple, et n'est toujours pas visible dans la liste des
fonctions!
Maintenant si tu veux qd même réfèrer plutôt à un autreclasseur
Exemple:
'''''premier classeur module standard
Sub autretest()
Dim mtxt As String
mtxt = Application.Run("autreclasseur.xls!aussilheur")
MsgBox mtxt
End Sub
''''autreclasseur module standard
Option Private Module
Public Function AussilHeur()
AussilHeur = Format(Now, "hh:mm")
End Function
'Ca marche aussi!
'lSteph
Cordialement.
--
lSteph
On 22 oct, 09:17, Jérôme MOUCHAIN <jmou...@gmail.com> wrote:
Je viens de tester, les modules en Option Private Module ne sont pas
accessibles pour les macros qui font une référence à la macro qui
contient le module.
Désolé, mais cela marche très bien ainsi (et lis bien la suite pour ref à autre)!
'Module2 Option Private Module Public Function dilHeur() dilHeur = Format(Now, "hh:mm") End Function
'Moduel1 Sub test() MsgBox dilHeur End Sub
Et elle est même utilisable dans la feuille et n'apparaît pas dans la liste, selon ta prime demande. Après , si ton but est d'utiliser des fonctions VBA qui sont utilisées uniquement dans le code comment y fais-tu appel? On irait que tu parles de ref ou Declare comme si c'étaient des dll Je ne vois pas où se pose ton pb, tu n'es pas du tout obligé de t'y prendre ainsi! Si tu as déjà dans un autre projet un module qui contient ces fonctions, exporte le depuis celui-là ex monmodule.bas et rapatrie le dans ton projet, ca fonctionnera comme indiqué plus haut en exemple!
Amha le plus simple, et n'est toujours pas visible dans la liste des fonctions!
Maintenant si tu veux qd même réfèrer plutôt à un autreclasseur Exemple: '''''premier classeur module standard Sub autretest() Dim mtxt As String mtxt = Application.Run("autreclasseur.xls!aussilheur") MsgBox mtxt End Sub
''''autreclasseur module standard
Option Private Module Public Function AussilHeur() AussilHeur = Format(Now, "hh:mm") End Function
'Ca marche aussi!
'lSteph
Cordialement.
-- lSteph
On 22 oct, 09:17, Jérôme MOUCHAIN wrote:
Je viens de tester, les modules en Option Private Module ne sont pas accessibles pour les macros qui font une référence à la macro qui contient le module.
Merci quand même.
JohnFuss.
Jérôme MOUCHAIN
Bonjour,
la structure de mes macros est la suivante, j'ai une MacroPrincipale.xla contenant mes fameuses Subs et Functions en Public et une MacroSecondaire.xla qui référence (VBE : Outils/Références) la MacroPrincipale.xla. Du coup pour utiliser les procédures de la MacroPrincipale depuis la MacroSecondaire je tape directement le nom de la procédure sans utiliser des Application.Run(). Du coup ça m'obligerait à repasser sur tous mes appels de procédures externes pour utiliser Application.Run, ça va me faire trop de boulot.... (150 macros secondaires à la louche), je pensais pouvoir intervenir directement dans la MacroPrincipale. Tant pis pour moi, merci pour tes conseils.
JohnFuss
Bonjour,
la structure de mes macros est la suivante, j'ai une
MacroPrincipale.xla contenant mes fameuses Subs et Functions en Public
et une MacroSecondaire.xla qui référence (VBE : Outils/Références) la
MacroPrincipale.xla. Du coup pour utiliser les procédures de la
MacroPrincipale depuis la MacroSecondaire je tape directement le nom
de la procédure sans utiliser des Application.Run(). Du coup ça
m'obligerait à repasser sur tous mes appels de procédures externes
pour utiliser Application.Run, ça va me faire trop de boulot.... (150
macros secondaires à la louche), je pensais pouvoir intervenir
directement dans la MacroPrincipale. Tant pis pour moi, merci pour tes
conseils.
la structure de mes macros est la suivante, j'ai une MacroPrincipale.xla contenant mes fameuses Subs et Functions en Public et une MacroSecondaire.xla qui référence (VBE : Outils/Références) la MacroPrincipale.xla. Du coup pour utiliser les procédures de la MacroPrincipale depuis la MacroSecondaire je tape directement le nom de la procédure sans utiliser des Application.Run(). Du coup ça m'obligerait à repasser sur tous mes appels de procédures externes pour utiliser Application.Run, ça va me faire trop de boulot.... (150 macros secondaires à la louche), je pensais pouvoir intervenir directement dans la MacroPrincipale. Tant pis pour moi, merci pour tes conseils.
JohnFuss
LSteph
Bonjour Jérôme,
là je cerne mieux ton souci, avec un peu de chance si tu as été conventionnel dans ton écriture tu as dû très certainement mettre comme de vivement recommandé un Call pour signifier l'appel avant le nom de chaque procèdure. Un rechercher remplacer depuis VBE devrait rapidement pourvoir à l'opération reste effectivement qu'il te faudra trouver une astuce ensuite ou te fader les 150 lignes en rouge pour ajouter les ") fermant l'instruction Il aurait probablement d'autres moyens en amont selon ce que j'envisage plus précisément dans ta demande mais a priori cela excède mes connaissances.
Cordialement.
-- lSteph
On 26 oct, 11:54, Jérôme MOUCHAIN wrote:
Bonjour,
la structure de mes macros est la suivante, j'ai une MacroPrincipale.xla contenant mes fameuses Subs et Functions en Public et une MacroSecondaire.xla qui référence (VBE : Outils/Références ) la MacroPrincipale.xla. Du coup pour utiliser les procédures de la MacroPrincipale depuis la MacroSecondaire je tape directement le nom de la procédure sans utiliser des Application.Run(). Du coup ça m'obligerait à repasser sur tous mes appels de procédures externes pour utiliser Application.Run, ça va me faire trop de boulot.... (150 macros secondaires à la louche), je pensais pouvoir intervenir directement dans la MacroPrincipale. Tant pis pour moi, merci pour tes conseils.
JohnFuss
Bonjour Jérôme,
là je cerne mieux ton souci, avec un peu de chance si tu as été
conventionnel dans ton écriture tu as dû
très certainement mettre comme de vivement recommandé un Call pour
signifier l'appel
avant le nom de chaque procèdure. Un rechercher remplacer depuis VBE
devrait rapidement pourvoir à l'opération
reste effectivement qu'il te faudra trouver une astuce ensuite ou te
fader les 150 lignes en rouge pour ajouter les ")
fermant l'instruction
Il aurait probablement d'autres moyens en amont selon ce que
j'envisage plus précisément dans ta demande mais a priori cela excède
mes connaissances.
Cordialement.
--
lSteph
On 26 oct, 11:54, Jérôme MOUCHAIN <jmou...@gmail.com> wrote:
Bonjour,
la structure de mes macros est la suivante, j'ai une
MacroPrincipale.xla contenant mes fameuses Subs et Functions en Public
et une MacroSecondaire.xla qui référence (VBE : Outils/Références ) la
MacroPrincipale.xla. Du coup pour utiliser les procédures de la
MacroPrincipale depuis la MacroSecondaire je tape directement le nom
de la procédure sans utiliser des Application.Run(). Du coup ça
m'obligerait à repasser sur tous mes appels de procédures externes
pour utiliser Application.Run, ça va me faire trop de boulot.... (150
macros secondaires à la louche), je pensais pouvoir intervenir
directement dans la MacroPrincipale. Tant pis pour moi, merci pour tes
conseils.
là je cerne mieux ton souci, avec un peu de chance si tu as été conventionnel dans ton écriture tu as dû très certainement mettre comme de vivement recommandé un Call pour signifier l'appel avant le nom de chaque procèdure. Un rechercher remplacer depuis VBE devrait rapidement pourvoir à l'opération reste effectivement qu'il te faudra trouver une astuce ensuite ou te fader les 150 lignes en rouge pour ajouter les ") fermant l'instruction Il aurait probablement d'autres moyens en amont selon ce que j'envisage plus précisément dans ta demande mais a priori cela excède mes connaissances.
Cordialement.
-- lSteph
On 26 oct, 11:54, Jérôme MOUCHAIN wrote:
Bonjour,
la structure de mes macros est la suivante, j'ai une MacroPrincipale.xla contenant mes fameuses Subs et Functions en Public et une MacroSecondaire.xla qui référence (VBE : Outils/Références ) la MacroPrincipale.xla. Du coup pour utiliser les procédures de la MacroPrincipale depuis la MacroSecondaire je tape directement le nom de la procédure sans utiliser des Application.Run(). Du coup ça m'obligerait à repasser sur tous mes appels de procédures externes pour utiliser Application.Run, ça va me faire trop de boulot.... (150 macros secondaires à la louche), je pensais pouvoir intervenir directement dans la MacroPrincipale. Tant pis pour moi, merci pour tes conseils.
JohnFuss
Jérôme MOUCHAIN
Merci pour ta réponse,
tu parles d'être conventionnel dans son écriture en utilisant le Call, je ne l'ai jamais utilisé, quel est l'intérêt (à part évidemment dans mon cas de retrouver facilement les procédures externes...
Si j'avais mis ces Call j'aurai pu boucler directement sur les lignes de codes de mes macros pour faire une mise à jour via du code VBA...
John.
Merci pour ta réponse,
tu parles d'être conventionnel dans son écriture en utilisant le Call,
je ne l'ai jamais utilisé, quel est l'intérêt (à part évidemment dans
mon cas de retrouver facilement les procédures externes...
Si j'avais mis ces Call j'aurai pu boucler directement sur les lignes
de codes de mes macros pour faire une mise à jour via du code VBA...
tu parles d'être conventionnel dans son écriture en utilisant le Call, je ne l'ai jamais utilisé, quel est l'intérêt (à part évidemment dans mon cas de retrouver facilement les procédures externes...
Si j'avais mis ces Call j'aurai pu boucler directement sur les lignes de codes de mes macros pour faire une mise à jour via du code VBA...
John.
LSteph
Re,
c'est juste une convention d'écriture et c'est facultatif, Call a ses usagers et aussi ses detracteurs, selon avantages et inconvénients (voir Aide) mais cette instructioni t'aurait effectivement permis comme je le suggérais. de traiter tes lignes de code que ce soit par rechercher remplacer ou par un autre moyen. Elle trouve aussi son intérêt dans la relecture d'un code on identifie plus vite qu'il s'agit d'un appel à une routine qu'un autre type d'instruction.
Cordialement.
-- lSteph
On 26 oct, 16:53, Jérôme MOUCHAIN wrote:
Merci pour ta réponse,
tu parles d'être conventionnel dans son écriture en utilisant le Call , je ne l'ai jamais utilisé, quel est l'intérêt (à part évidemmen t dans mon cas de retrouver facilement les procédures externes...
Si j'avais mis ces Call j'aurai pu boucler directement sur les lignes de codes de mes macros pour faire une mise à jour via du code VBA...
John.
Re,
c'est juste une convention d'écriture et c'est facultatif, Call a ses
usagers et aussi ses detracteurs, selon avantages et inconvénients
(voir Aide) mais cette instructioni t'aurait effectivement permis
comme je le suggérais.
de traiter tes lignes de code que ce soit par rechercher remplacer ou
par un autre moyen.
Elle trouve aussi son intérêt dans la relecture d'un code on identifie
plus vite qu'il s'agit d'un appel à une routine
qu'un autre type d'instruction.
Cordialement.
--
lSteph
On 26 oct, 16:53, Jérôme MOUCHAIN <jmou...@gmail.com> wrote:
Merci pour ta réponse,
tu parles d'être conventionnel dans son écriture en utilisant le Call ,
je ne l'ai jamais utilisé, quel est l'intérêt (à part évidemmen t dans
mon cas de retrouver facilement les procédures externes...
Si j'avais mis ces Call j'aurai pu boucler directement sur les lignes
de codes de mes macros pour faire une mise à jour via du code VBA...
c'est juste une convention d'écriture et c'est facultatif, Call a ses usagers et aussi ses detracteurs, selon avantages et inconvénients (voir Aide) mais cette instructioni t'aurait effectivement permis comme je le suggérais. de traiter tes lignes de code que ce soit par rechercher remplacer ou par un autre moyen. Elle trouve aussi son intérêt dans la relecture d'un code on identifie plus vite qu'il s'agit d'un appel à une routine qu'un autre type d'instruction.
Cordialement.
-- lSteph
On 26 oct, 16:53, Jérôme MOUCHAIN wrote:
Merci pour ta réponse,
tu parles d'être conventionnel dans son écriture en utilisant le Call , je ne l'ai jamais utilisé, quel est l'intérêt (à part évidemmen t dans mon cas de retrouver facilement les procédures externes...
Si j'avais mis ces Call j'aurai pu boucler directement sur les lignes de codes de mes macros pour faire une mise à jour via du code VBA...
John.
LSteph
...outre cet avantage que call aurait pu te procurer, certains pensent résolument que de par son caractère facultatif elle serait inutile, on est pas obligé d'être d'accord autre avantage que sa propre relecture extrait d'un débat dans ce forum:
| Bien sûr, mais le mot Call, hérité du Basic d'autrefois est super flu en VBA
L'utilisation du mot "Call" permet à l'application au moment de la comp ilation d'identifier le lieu où se situe la procédure appelée. Conséquenc e, l'exécution du code serait plus "rapide". De plus, dans certains cas, cela pourrait a ider à la lecture du code en discriminant les procédures appelées et les méthodes supportées par le code VBA.
Évidemment, personne ne dit que la présence de ce mot "Call" soit obl igatoire ! ;-)
Salutations!
On 26 oct, 16:53, Jérôme MOUCHAIN wrote:
Merci pour ta réponse,
tu parles d'être conventionnel dans son écriture en utilisant le Call , je ne l'ai jamais utilisé, quel est l'intérêt (à part évidemmen t dans mon cas de retrouver facilement les procédures externes...
Si j'avais mis ces Call j'aurai pu boucler directement sur les lignes de codes de mes macros pour faire une mise à jour via du code VBA...
John.
...outre cet avantage que call aurait pu te procurer, certains pensent
résolument que de par son caractère facultatif elle serait inutile, on
est pas obligé d'être d'accord autre avantage que sa propre relecture
extrait d'un débat dans ce forum:
| Bien sûr, mais le mot Call, hérité du Basic d'autrefois est super flu en VBA
L'utilisation du mot "Call" permet à l'application au moment de la comp ilation
d'identifier le lieu où se situe la procédure appelée. Conséquenc e, l'exécution
du code serait plus "rapide". De plus, dans certains cas, cela pourrait a ider
à la lecture du code en discriminant les procédures appelées et les méthodes
supportées par le code VBA.
Évidemment, personne ne dit que la présence de ce mot "Call" soit obl igatoire !
;-)
Salutations!
On 26 oct, 16:53, Jérôme MOUCHAIN <jmou...@gmail.com> wrote:
Merci pour ta réponse,
tu parles d'être conventionnel dans son écriture en utilisant le Call ,
je ne l'ai jamais utilisé, quel est l'intérêt (à part évidemmen t dans
mon cas de retrouver facilement les procédures externes...
Si j'avais mis ces Call j'aurai pu boucler directement sur les lignes
de codes de mes macros pour faire une mise à jour via du code VBA...
...outre cet avantage que call aurait pu te procurer, certains pensent résolument que de par son caractère facultatif elle serait inutile, on est pas obligé d'être d'accord autre avantage que sa propre relecture extrait d'un débat dans ce forum:
| Bien sûr, mais le mot Call, hérité du Basic d'autrefois est super flu en VBA
L'utilisation du mot "Call" permet à l'application au moment de la comp ilation d'identifier le lieu où se situe la procédure appelée. Conséquenc e, l'exécution du code serait plus "rapide". De plus, dans certains cas, cela pourrait a ider à la lecture du code en discriminant les procédures appelées et les méthodes supportées par le code VBA.
Évidemment, personne ne dit que la présence de ce mot "Call" soit obl igatoire ! ;-)
Salutations!
On 26 oct, 16:53, Jérôme MOUCHAIN wrote:
Merci pour ta réponse,
tu parles d'être conventionnel dans son écriture en utilisant le Call , je ne l'ai jamais utilisé, quel est l'intérêt (à part évidemmen t dans mon cas de retrouver facilement les procédures externes...
Si j'avais mis ces Call j'aurai pu boucler directement sur les lignes de codes de mes macros pour faire une mise à jour via du code VBA...