Le mode Edition d'Excel bloque l'exécution des macros (et pas que !)

Bonjour,
Je suis en train d'installer une macro dans un fichier pour qu'il soit sauvegardé et se ferme automatiquement au bout d'un certain temps, par exemple au cas où l'utilisateur quitte son poste en laissant le fichier ouvert. Pour ce faire, je me suis grandement inspirée d'un post de 2015 sur ce forum. Merci à vous !
Tout fonctionne parfaitement ... sauf dans le cas où l'utilisateur a saisi du texte dans une cellule et s'est arrêté là sans "valider" sa saisie en appuyant sur "Enter", "Tab" ou ou cliquant sur une autre cellule. Excel reste donc en attente en mode Edition, tous les menus sont grisés et les macros éventuelles qui tourneraient en arrière-plan sont également mises en attente (c'est le cas de ma fameuse macro qui décompte le temps...).
Je pense qu'il y a quelque chose à faire puisque si l'on fait CTRL-S, Excel sort du mode Edition avant de sauvegarder le fichier. J'aimerais bien savoir ce que Microsoft utilise comme code juste avant son "Save" pour contourner ce problème...
L'un de vous aurait-il la solution ?

Bonjour,

La solution est d'insérer dans votre macro, la frappe de la touche Entrée via cette procédure à insérer dans un module :

Option Explicit

Private Declare PtrSafe Sub keybd_event Lib "user32.dll" (ByVal bVk As Byte, ByVal bScan As Byte, ByVal dwFlags As Long, ByVal dwExtraInfo As Long)

Const VK_RETURN = &HD        'touche Entrée

Sub presser_entrée()
    'frappe touche Entrée
    keybd_event VK_RETURN, 0, 0, 0
    DoEvents
End Sub

Bonjour,

CTRL+S correspond à une action de l'utilisateur donc cela me semble normal que l'on sorte du mode édition. Je n'ai pas retrouvé le post de 2015 cité dans le message mais j'ai fait un test avec le fichier ci-joint (extrêmement basique), le mode édition est bien abandonné après un certain délai (ici 15 secondes) sans certaines actions (modifié une cellule, se déplacer, sauvegarder) de l'utilisateur, un message est affiché juste pour indiquer que le fichier serait sauvegardé puis fermé. Je ne sais pas si cela serait réutilisable dans votre contexte.

Voir le code associé à Module1, Feuil1 et ThisWorkbook.

Cdlt,

Cylfo

Bonjour,

Edit : voir post de Cylfo

Pour ma part, j'ai réalisé la même chose pour mon boulot mais à l'époque je n'avais pas tenu compte de cas de figure
Sinon je ne pense que ce soit possible

Crdlt.

Merci beaucoup, Thev et Cylfo ! A la première lecture, l'écriture de votre code dépasse un peu mes connaissances, mais je vais décortiquer cela plus attentivement... En tout cas, le fichier test de Cylfo agit comme je le souhaite et je vais tenter d'adapter mon fichier avec ton code. Si cela vous intéresse, je joins mon fichier "Essai fermeture automatique" tel que je l'avais préparé, beaucoup plus simpliste que vos codes à tous deux, mais je ne suis pas une pro !!!

P.S. Je me laisse le week-end avant de clore le post au cas où j'aie encore l'une ou l'autre question, si vous le voulez bien...

Ok et à ta disposition si tu as des questions.

Cdlt,

Bonjour Domino67,

J'ai regardé le code de ton fichier, il ne peut pas fonctionner tel que tu le souhaites car la méthode OnTime programme l'exécution d'une procédure à une heure donnée si Excel est "disponible" sinon l'exécution de la procédure est annulée (il y a un paramètre qui permettrait de ne pas l'annuler tout de suite mais il ne ferait pas sortir Excel du mode édition).

Quelques explications / informations concernant le code proposé :

La procédure "DelaiAvantSauveEtFerme" est appelée à l'ouverture du classeur et s'exécute en boucle (*) mais la fonction DoEvents suspend son exécution pour permettre au système de traiter d'autres actions / événements tout en reprenant la main aussitôt après et donc de se poursuivre aussi s'il ne se passe rien (dont une saisie en suspend). Le début du décompte de la fermeture (variable publique phDebut) est réinitialisé après certains événements (voir code dans ThisWorkbook) et la boucle s'interrompe lorsque Timer devient plus grand que phDebut + <un nombre de secondes>. En sortie de boucle si le décompte n'a pas été interrompu (fermeture volontaire du fichier), la touche Escape est simulée et si Excel est en mode édition, cela l'en fait sortir et la sauvegarde / fermeture automatique peut avoir lieu.

Je n'ai pas poussé les tests mais si tu utilises cette technique (il y en a peut-être d'autres que je ne connais pas), il faut pousser les tests et vérifier entre autres ce qu'il se passe lorsque tu as plusieurs fichiers d'ouverts et éventuellement si dans cet autre fichier tu as un formulaire d'ouvert ou une macro qui s'exécute. Si dans ton fichier, tu exécutes d'autres macro, il faut prévoir de réinitialiser phDebut sinon le classeur risque de se sauvegarder et se fermer dès que la macro se termine, par ailleurs l'exécution d'une macro dans ce classeur suspendra l'exécution de la procédure "DelaiAvantSauveEtFerme".

(*) : Inconvénient : la procédure "Workbook_Open()" reste active jusqu'à la fin de l'exécution de la procédure "DelaiAvantSauveEtFerme", c'est pour cela qu'il faut que cette instruction soit la toute dernière de la procédure "Workbook_Open()".

Cdlt,

Cylfo

Aie !! Je viens de faire un test dont le résultat me semble rendre la solution caduque ... visiblement CTRL+F recherche et CTRL+H remplacement ne fonctionnent pas lorsque la procédure "DelaiAvantSauveEtFerme" s'exécute ... cela me semble rédhibitoire et il y a peut-être d'autres fonctions qui ne s'exécutent pas correctement ... Je vais creuser un peu ...

C'est vraiment sympa !

Hier soir, j'avais bien réussi à décortiquer et à comprendre ton code, et tes explications ci-dessus me le confirment. Un doute, toutefois, en ce qui concerne la 2e variable déclarée (elle commence par pl, je crois, désolée je n'ai pas mon ordi ce weekend et je ne vois pas les macros sur mon téléphone 😨), déclarée as boolean, = false dans le code. J'ai un peu de mal à voir à quoi ça correspond...

En effet, hier, je n'ai pas réussi à faire fonctionner Doevents et insert {Enter} dans ma macro, je comprends à présent que c'est à cause de la méthode OnTime.

il faut que je me renseigne aussi sur ce que l'utilisateur est censé faire dans ce fichier : saisie simple ou d'autres actions, recherche/remplacement, etc. Je crois que c'est assez simpliste mais j'ai toujours tendance à prévoir le pire, d'où ma question. S'il s'agit uniquement de saisies, je peux les faire passer par un formulaire qui placera les éléments aux bons endroits et fermera le fichier d'office 🙂.

Bon week-end.

Cdlt.

plStopTimer (p pour public, l pour logique[booleén]), vieille habitude de préfixer les variables ... La boucle de décompte s'effectue tant que le temps à décompter n'est pas échu et que cette variable est égal à faux. Elle est initialisée à vrai dans l'événement Workbook_BeforeExit, ce qui provoque la sortie de la boucle et testée ensuite pour ne sauvegarder et fermer le fichier que si elle est toujours valorisée à faux (ce qui indique que la boucle n'a pas été interrompue par une action de l'utilisateur).

J'ai testé une autre solution (externaliser le code dans un autre classeur) mais cela provoque le même effet sur l'action de rechercher / remplacer. Pour le formulaire cela ne résoudra pas le problème, si l'utilisateur laisse le formulaire ouvert sans rien faire, le fichier ne pourra pas se sauvegarder / se fermer.

Je continue de chercher mais quelqu'un d'autre a peut-être la solution ?

Bonjour,

Exemple avec le module que j'ai fourni :

@thev,

avec ton fichier, j'ai le même souci, la recherche n'aboutie pas

alors qu'une fois la procédure achevée, la recherche s'effectue correctement.

Cdlt,

Cylfo

@Cylfo

Le mode de fonctionnement que j'ai proposé n'autorise certes pas toutes les opérations sur une feuille mais il permet de la modifier.

Ensuite si le demandeur passe par un formulaire, il n'est plus nécessaire de modifier directement la feuille auquel cas le blocage d'une cellule en mode édition ne peut plus se produire et le problème du demandeur est résolu d'office.