Discussion :

[Mic13710]

Bonsoir le forum,

Je suis en train de mettre la touche finale à mon projet, et comme je ne souhaite pas que l'utilisateur lambda aille fouiller et/ou tombe sur mon code en cas d'arrêt d'exécution, j'ai activé le verrouillage du projet à l'affichage avec un mot de passe. Ce n'est pas une protection d'une grande efficacité comme chacun le sais, mais comme mes utilisateurs ne sont pas des cadors de l'informatique, c'est largement suffisant.

L'ennui c'est qu'une fois ce verrouillage activé, mon code ne fonctionne plus !

Et chose étrange, quand j'active les macros, excel me demande le mot de passe du projet, et si je ne le donne pas, ça plante sur la recherche d'un fichier. Si je le donne, alors tout roule.

A quoi bon alors mettre un code de protection si c'est pour le donner à mes utilisateurs pour pouvoir faire tourner le programme ?

Encore plus étrange, si j'ajoute à mon code un MsgBox avant l'instruction de recherche de fichier qui plante, ça passe sans avoir à renseigner le mot de passe.

Bref, je ne comprends pas pourquoi excel me demande le mot de passe du verrouillage de l'affichage au lancement (y'a t'il moyen de l'inhiber), et pourquoi je dois mettre un MsgBox juste avant l'instruction de recherche de fichier pour éviter que ça plante alors que sans verrouillage, mon code fonctionne normalement.

Si vous avez des idées, je suis preneur.

D'avance merci.

[unparia]

Bonjour
Un verrouillage à l'affichage ... verrouille à l'affichage. Telle (et nulle autre) est sa vocation.
C'est comme la serrure de la porte d'entrée de ton appartement. Si tu la fermes à clef, toute personne (y compris toi) devra utiliser cette clef pour ouvrir cette porte.
Si tu voulais par contre interdire l'accès à un coffre-fort à tout visiteur déjà entré (avec clef si serrure fermée ou sans clef si serrure ouverte), il te faudrait protéger ce coffre-fort.

Les moyens de cacher les macros, les rendre incompréhensibles, etc ... sont divers et variés. Tous sont assez (pour ne pas dire très) facilement déjoués. Ce sujet est fréquent sur ce forum. L'utilisation du moteur de recherche dont il est doté te conduira à de nombreuses et récurrentes discussions concernant cet aspect.

EDIT : tu ferais par contre bien de dépenser ton énergie à des choses plus "sévères", telles qu'éviter :

ou tombe sur mon code en cas d'arrêt d'exécution

Un code bien construit ne doit pas en arriver à cela

[Invité]

Bonjour,
Rassures moi, dans ton projet Vba tu as fait un click droit sur projet et tu as choisi mettre un mot de passe?

Le verrouillage du projet n'interdit pas l'utilisation des macros mais interdit d'accéder au code source!

Ensuite la sécurité ne dépend que de ce qu'il est indiscret!

Je ne protège jamais mes sources! De toutes les façons l'utilisateur me demandera qu'est ce qui faut que je fais?

Et utiliser un coffre numérique don j'ai oublié le code pour protéger mes mots de passe trop peut pour moi!
Le cas échéant je fais une Dll.

[Mic13710]

Merci pour vos réponses.

@unparia, le fait de mettre un mot de passe pour verrouiller l'affichage du code VBA n'interdit pas (en principe) le code de fonctionner. Je le fais tout le temps parce que encore une fois c'est suffisant pour mes utilisateurs. C'est la première fois que je vois une demande de mot de passe pour déverrouiller le code à l'ouverture d'un fichier, d'où mon étonnement.
Je suis bien d'accord qu'un code bien construit ne devrait pas activer la fenêtre de débugage. Mais comme il est assez complexe (en tout cas pour moi) et toujours en période de débug, je suis parfois confronté à ce genre de chose. Le code est alors en open bar ce qui ne me convient pas bien entendu, alors qu'avec le verrouillage, il n'est pas accessible. Tant pis si ça a planté. C'est un programme pour notre club, qui n'est pas essentiel ça n'a donc qu'une incidence très limitée.
Par ailleurs, j'ai supprimé tous les menus Excel et pratiquement tous les items du menu fichier pour éviter que mes utilisateurs puissent accéder au code. J'ai aussi mis un mdp général sur le fichier pour le cryptage. Il serait dommage que tout ce bel édifice soit mis à mal par un accès au code non sollicité.

@dysorthographie, je ne sais pas encore travailler avec les dll, mais j'ai fait sensiblement la même chose avec un .xlam dédié à mon fichier et installé dans le dossier AppData\Roaming qui me permet de sécuriser une partie de mes codes. Je l'installe au lancement et le désinstalle à la fermeture. Mais si tu as un lien à me donner pour faire ça plus simplement avec des .dll, je suis preneur.

En retravaillant la chronologie de mon code de départ, j'ai réussi à le faire fonctionner normalement (sans un msgbox), mais j'ai toujours la demande du mot de passe. Certes il me suffit d'annuler pour lancer le démarrage, mais ce n'est pas l'idéal. Me reste plus qu'à trouver comment faire pour l'éviter. Si vous avez des pistes, je suis preneur.

[unparia]

Mais comme il est assez complexe (en tout cas pour moi) et toujours en période de débug, je suis parfois confronté à ce genre de chose.

Désolé, mais je persiste et signe. C'est à ce genre de maladresse que tu dois PRIORITAIREMENT dédier ton énergie.
Pour le reste : que crains-tu ? Que l'on te "vole" un code qui comporterait de telles maladresses ? Tu plaisantes ?
Et si ce n'est que pour éviter qu'on le bidouille et commette des bêtises --->> fais donc travailler en miroir sur un modèle.
Dans un cas comme dans l'autre : tu perds ton temps.
Je te laisse personnellement là.
Bonne chance

[Mic13710]

Je ne vais pas commenter une réponse complètement à côté de ma question.

Il n'est pas question ici de savoir si mon code est bon ou pas, ce n'est pas le problème, mais pourquoi excel me demande le mdp d'affichage alors que normalement il ne devrait pas.

Entre temps, j'ai localisé à partir de quel moment le code demande le mot de passe.

C'est à l'installation de la référence .xlam avec l'instruction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ThisWorkbook.VBProject.References.AddFromFile (....\mon fichier .xlam)

Peut-être que cette installation nécessite que le code soit accessible, mais alors pourquoi en annulant la demande de mdp l'installation se fait quand même ? Mystère.

Comment puis-je faire, avec la protection de l'affichage bien entendu, pour contourner cette demande ?

Y a t'il un code VBA pour l'inhiber au moins temporairement ?

[joe.levrai]

Bonjour,

toute manipulation automatisée du projet VBA nécessite qu'il soit déverrouillé, au même titre qu'une manipulation manuelle.

que ce soit de la manipulation de références, compléments, lignes de procédures etc....

ce qui est parfaitement logique ! Sinon on pourrait facilement aller copier l'intégralité du projet et le coller dans un nouveau fichier pour le consulter, sans saisir le mot de passe qui verrouille ledit projet.

Revoit ton approche, en supprimant les manipulation qui se réalisent au sein de ton projet. Ou tout simplement en ne mettant aucun mdp de protection, et en massacrant tes procédures à coup de On Error Goto Etiquette (qui se chargera de stopper la procédure et d'afficher un msgbox explicatif par exemple).

Une alternative que je n'utiliserais personnellement pas : déverrouiller le projet par procédure VBA, charger le fichier, et reverrouiller le projet
voir ce fil de discussion par exemple : https://www.developpez.net/forums/d1...ba-d-classeur/

[Invité]

Bonjour,
Tu trouveras certaines explication pour faire un dll Ici: https://www.developpez.net/forums/d1...l/#post8961013

Le lien que je donne dans ce poste n'est plus d'actualité et je le déplore mais Visual Studio 6 est tombé dans le domaine publique maintenant!

En cherchant sur le web tu devrais le retrouver!

Je reste disponible pour plus amples explication.

Tu pourras utiliser ta dll dans Excel,il te suffiras l'installer plus de manipulation du projet Vba!

Maintenant d'une manière générale le on error est à proscrire surtout si tu ne sais pas le gérer!

Dans d'autres langue de programmation on appel ça des exceptions! Elles doivent être exceptionnelles indépendant de sa volonté, tout ce qui est à l'extérieur de l'application! Coupure réseau,imprimante HS etc...

[Mic13710]

Merci dysorthographie, je vais aller creuser les dll pour essayer de les appliquer à mon projet.

Pour le moment je suis avec mon .xlam qui fonctionne bien puisque j'ai solutionné mon souci. C'était bien un problème d'installation de référence qui me mettait la panique.
Plutôt que de m'escrimer à passer outre la demande de mdp, j'ai installé mon fichier .xlam dans un répertoire à la racine du disque C. Comme (presque) tout le monde a un disque C, je n'ai plus besoin de désinstaller la référence, ce qui du même coup ne nécessite pas de réinstallation et donc pas d'appel du mdp du VBA.
Je vais maintenant me pencher sur les dll et voir comment je peux les utiliser en lieu et place de mon xlam.

Le sujet est maintenant résolu. Merci à tous.