Userform, délais de réutilisation d'un bouton

Question

J'imagine que poster ici est une étape de franchie dans l'apprentissage de VBa! Voilà quelques mois que le virus VBa m'a piqué, sans remède... ... ça tombe bien, je n'en cherche pas... Merci à tous les gens qui ont posté et surtout à ceux qui ont répondu, ce forum est devenu mon meilleur professeur! Brèf, j'ai créé un userform pour une application tactile sur tablette. Ce Userform recréé un pavé numérique, avec les touches de 0 à 10. Quand on clique sur un bouton ("commandbutton") il faut un certain délai (1s, peut-être moins) avant que ce bouton redevienne utilisable. Quand un opérateur clique, trop vite, 2 fois sur le même bouton, il n'y a seulement qu'une saisie de prise. Existe-t-il un code ou un paramétrage de la commande pour réduire ce délai et saisir par exemple le nombre 33 en très peu de temps? Merci par avance pour vos réponses...

retraite8 · Answer

Il y a des chances que ton code puisse être accéléré. Mais, car, il y a toujours un, mais ... il faudrait le voir ce code. Soit le code sous balise (le bouton Code au haut du message ou le fichier lui-même ... anonymisé bien sûr. Joseph...

retraite8 · Answer

J'ai allégé un peu ton code. Malgré cela et n'ayant pas de tablettes supportant un Excel avec macro pour vérifier. Je ne pense pas avoir réussi à améliorer le délai entre deux "doigtés" sur un même bouton. Quoi qu'il en soit, je te laisse tester ce chiffrier. Joseph...

eriiic · Answer

A mon avis c'est fait exprès pour filtrer les 'rebonds' et éviter des erreurs intempestives. J'ai essayé d'autres objets (image, label) mais c'est pareil pour tous. Si réglage il y a ça ne sera, je pense, que dans la base de registre si ça peut orienter tes recherches. Au risque d'affecter éventuellement d'autres applis... A tout hasard teste quand même en baissant ton délai du double-clic des fois qu'il influe également ici. eric...

MFerrand · Answer

Ouf ! Je dois dire que j'ai pris peur en voyant ton code ! Je préconiserais volontiers une cure drastique... J'ai d'ailleurs commencé par renommer les contrôles, et effacer la totalité du code. Ma proposition repose sur une seule procédure principale : Sub Ajout(n) Static nb As String Select Case n Case 0 To 9: nb = nb &amp; n Case "C": If nb &lt;&gt; "" Then nb = Left(nb, Len(nb) - 1) Case "T": nb = "" Case "V" Me.Hide ActiveCell = nb: nb = "" ActiveCell.Offset(1).Select Application.OnTime Now + TimeValue("00:00:01"), "pave" End Select tbAffich.Value = nb End Sub A part Exit, qui ferme, tous les autres boutons activent cette proc. en lui passant une valeur : 0 à 9, C (effacement dernier caract.), T (effacement total), V (validation). La validation déplace la sélection (pour le cas où l'on veut poursuivre), masque le Userform et rappelle la proc. appelante avec temporisation d'une seconde... Tout cela peut être modifié... Je me demande d'ailleurs à quoi tu destines en fin de compte ton appli. Tu envoies un nombre à la cellule. La saisie est mémorisée en texte mais Excel convertit automatiquement en nombre, la chaîne étant numérique. Si tu souhaites l'avoir sous forme texte, il faudra aménager la sortie... J'ai remplacé la ListBox par une TextBox, qui ne sert cependant que pour l'affichage. Alors, tout cela ne règle cependant pas le problème de réactivité des boutons ! Comme l'a noté Eric, la chose dépend pour une part de ton réglage du double-clic. J'ai doublé l'envoi du nombre à la procédure Ajout par l'évènement Click par un envoi à partir de l'évènement DblClick, ce qui améliore un peu la situation... Cordialement...

retraite8 · Answer

MFerrand, je serai toujours ébaroui, sidéré, estomaqué par tes connaissances en Vba. Moi, pauvre autodidacte à la cervelle défaillante, il ne me reste pas beaucoup d'alternative que d'aller me bercer. Un Joseph admiratif...

MFerrand · Answer

Voyons ! Ça tient toujours pas mal la route... et on en apprend tous tous les jours, encore ! Bon dimanche...

retraite8 · Answer

Dans le formulaire, au haut, la macro Ajout, Remplace les deux "ActiveCell" par Range("xx") ou par Cells(laligne, le colonne) Exemple : Range("C1") ou Cells(1, 3) ou encore Cells(1, "C") Pour la 2e question, je ne serais dire ... Joseph...

MFerrand · Answer

Pour la 2e question, c'est moi qui ai fait en sorte qu'il se ferme et qu'il réapparaisse (je ne voyais pas la cellule sélectionnée ! ) Il suffit de supprimer les 2 lignes concernées : Me.Hide et Application.OnTime.... (j'y reviendrai). Je venais de pondre un long message sur les méfaits du code enregistré (en guise d'introduction) et les moyens d'y pallier et de l'épurer, de façon que le code soit plus court, et son exécution plus rapide ! Et il est visiblement passé à la trappe sans prévenir ! Pas le temps de réécrire tout ça ! On aura peut-être l'occasion d'y revenir.....

eriiic · Answer

Apparemment tu es abonné Si tu as Chrome je te conseille d'installer Lazarus Ca te sauvegarde toute saisie d'un formulaire et te permet de la restaurer facilement en cas de coupure. Existe aussi pour firefox. eric...

MFerrand · Answer

Je poursuis donc sur mon second volet de recommandations préalables, motivé par les blocages récurrents sur un certain nombre d'éléments fonctionnels que tu opérais...

Ces action de paramétrages des réactions de l'interface n'ont d'intérêt que si elles font gagner du temps d'exécution...

Application.ScreenUpdating = False

La plus utilisée ! Utile dès lors que l'on intervient sur la feuille d'une façon qui entraînera une mise à jour de l'affichage. Cette instruction bloque la mise à jour. Le gain, lorsqu'on opére par exemple une intervention modifiant une feuille ligne par ligne, peut s'avérer particulièrement conséquent.

Excel rétablit automatiquement la mise à jour de l'affichage en fin de macro. Inutile donc de remettre cette valeur à True à la fin. Ce n'est utile que si l'on a besoin d'actualiser l'affichage en poursuivant la macro, donc avant la fin...

Application.DisplayAlerts = False

Cette instruction inhibe les messages d'alerte que l'application émet avant de procéder à certaines opérations, afin d'obtenir confirmation ou infirmation de l'utilisateur.

Elle n'est utile que lorsque l'on est exposé à ce type de message, ce qui est le cas quand on ne peut l'éviter par une commande appropriée.

Excel utilisera le choix correspondant à l'action sélectionnée par défaut (bouton présélectionnée de la boîte de dialogue). Il y a donc lieu de prévoir les messages susceptibles de survenir et savoir ce qui sera fait sans que l'on soit prévenu...

Excel opére le retour à la normale en fin de macro, comme précédemment, il n'y a donc pas lieu de revenir à True.

Application.EnableEvents = False

Cela sert à désactiver les évènements de l'Application. Plus précisément l'interception de ces évènements pour exécuter un code lorsqu'ils surviennent. Cela ne présente donc d'utilité que lorsque l'on a codé des procédures évènementielles pour réagir à certains évènements, et que selon les circonstances il convient d'interrompre ces réactions auxdits évènements.

Il convient de réactiver (True) lorsqu'on reprend le cours normal... Se méfier des erreurs d'exécution susceptibles de survenir avant rétablissement à True, qui pourraient les désactiver pour toute la session (tant qu'on n'aura pas fermé et rouvert Excel !)

Il s'agit des évènements de l'Application, donc aucun effet sur un Userform... (j'ai pu le constater sur un sujet récent...)

Application.Calculation = xlCalculationManual

Passage en mode Calcul manuel : les recalculs automatiques ne se font plus...

Cela n'est justifié que si des recalculs fréquents et longs viennent impacter l'usage normal d'Excel...

Je préconise de n'y recourir que si cela s'avère indispensable, à l'expérience, ce qui n'est pas le cas dans la grande majorité des cas...

Au contraire, si l'on a besoin au cours d'une macro, d'une valeur mise à jour par formule dans une cellule, mise à jour résultant du code précédemment exécuté dans la même macro, on est souvent obligé d'introduire une commande destiné à forcer le recalcul avant de prélever la valeur pour être sûr de la récupérer après mise à jour !

J'ai oublié les autres commandes de ce type que tu exécutais, mais je crois qu'au regard de l'exécution du code il n'y avait aucun effet particulier à en attendre...

J'insiste sur la nécessité d'utiliser ces outils, indéniablement utiles dans certaines situations, en connaissance de cause, et dans les cas où ils ont un rôle effectif à jouer.

Il convient de ne pas perdre de vue que des interactions nombreuses avec l'interface (Excel) auront toujours un effet de ralentissement sur l'exécution du code, et que la meilleure façon de l'accélérer et fluidifier au mieux l'utilsation d'Excel avec VBA, consiste à réduire ces interactions au minimum (exemple type : on prélève les données à traiter, éventuellement par transfert sur un tableau, plus rapide d'accès pour la suite, on traite les données comme prévu, hors Excel, en stockant s'il y a lieu les résultats dans une tableau, on restitue dans Excel le résultat final, à la fin seulement ! plutôt que d'opérer des traitements mettant des données à jour ligne par ligne, voire cellule par cellule...)

(à suivre)

MFerrand · Answer

Je sais !!! Là je pense que j'ai fait une fausse manoeuvre involontaire, en actionnant un autre bouton que Envoyer lors de la temporisation m'indiquant un message survenu... Mais le problème principal que je subodore (parce que je ne l'avais pas ou pas de la même façon avec les anciens opérateurs), je l'ai depuis que je suis sur un abonnement fibre avec mon nouvel opérateur... C'est évidemment très rapide (en local si je puis dire!), cependant les réponses sont tributaires des réseaux qui nous relient principalement à la métropole (fameux câble "Safe" sous-marin...) souvent affectés par des travaux de maintenance et on sent toujours à certaines heures que le débit de ces réseaux n'est pas illimité, sans parler des autres éléments intervenant dans l'acheminement. J'ai assez souvent un avis de non réponse momentané à une requête qui survient de façon immédiate, comme si le serveur qui me l'envoie me répond sans avoir pris le temps d'attendre d'avoir lui même la réponse... ! Un second clic immédiat, et elle arrive. Mais si le phénomène se produit simultanément à l'envoi d'une réponse de ma part, elle passe à la trappe... A l'expérience des cas où cela peut se produire (généralement avec fichier joint, ou sinon message particulièrement long) j'arrive à éviter la plupart du temps... Il faudra que je questionne la hot-line à l'occasion (quand je rentrerai, pas le temps en ce moment, je prépare mon départ dans quelques jours...) Bon dimanche à toi...

eriiic · Answer

Quelle que soit la cause ça reste ch... quand tu as passé 10 min à rédiger. D'où l'intérêt de la sauvegarde auto. Bon voyage et (?) bonnes vacances eric...

MFerrand · Answer

Il ne faut pas te laisser déstabiliser, c'est bien plus simple qu'il n'y paraît... Sub Ajout(n) Static nb As String Select Case n Case 0 To 9: nb = nb &amp; n Case "C": If nb &lt;&gt; "" Then nb = Left(nb, Len(nb) - 1) Case "T": nb = "" Case "V": ActiveCell = nb: nb = "" End Select tbAffich.Value = nb End Sub La procédure va être appelée par les autres bouton en lui passant un argument. Pas de difficulté sur ce point je pense... n, l'argument est laissé de type Variant, les boutons numériques vont lui envoyer chacun un nombre, les autres une lettre (C pour supprimer un caractère, T pour tout effacer, V pour valider (soit affecter le resultat à une cellule et ne pas le conserver pour la suite... La procédure est dotée d'une variable statique (nb, déclarée avec l'instruction Static). Une telle variable, qui ne peut figurer que dans une procédure, contrairement aux autres variables de procédures qui disparaissent à la fin de l'exécution, voit sa valeur conservée entre deux appels de la procédure. Elle va donc être utilisée pour conserver le résultat, résultat qui est complété par chaque appel de la procédure, jusqu'à ce que l'on valide ou annule. Il n'y a donc plus lieu de prévoir son stockage intermédiaire ailleurs, c'est la procédure elle-même qui le conserve. Select Case est une instruction décisionnelle (comme If... Then... Else...), qui permet comme tu peux le voir de cerner les conditions de décision selon une liste de cas. Au cas particulier selon la valeur envoyée en l'appelant. Dans une telle situation, sa structure est plus souple d'emploi que If... Then... Else... (il est dit aussi qu'elle serait plus rapide...) Si elle reçoit un nombre de 0 à 9 : elle le concatène au résultat (variable nb) Si elle reçoit un C : elle élimine le dernier caractère du résultat Si elle reçoit un T : elle efface le résultat ("") Si elle reçoit un V : elle affecte le résultat (et l'efface de la variable). En fin de procédure le résultat atteint est affecté à une TextBox pour information de l'utilisateur... &#91;NB: les deux-points (:) séparant deux instructions sur la même ligne sont un séparateur de lignes de code (permet d'écrire plusieurs lignes de code sur la même ligne physique), de même qu'à l'inverse, espace+underscore ( _) constitue un caractère de continuité de ligne de code (permet de l'écrire sur plusieurs lignes physiques).&#93; Pour l'affecter toujours à la même cellule, tu remplaces ActiveCell par une indication de cellule. J'ai supprimé ici le déplacement de la sélection que j'avais introduit, ainsi que le masquage momentané du Userform.... Si tu veux faire varier la cellule réceptrice, selon choix de l'utilisateur, tu déclares une variable module (publique) dans le Userform (ou tu utilises la propriété Tag...) et tu fais choisir dans la procédure appelante du Userform l'utilisateur (Application.InputBox, qui permet de choisir une cellule et renvoyer un objet Range (que tu affectes à la variable du Userform, ou tu initialises son .Tag avec l'adresse de la cellule, avec ouverture du Userform. Et tu disposeras alors d'une cellule variable choisie pour affecter le résultat lors de la validation. Cordialement. Edit : Merci Eric ...