IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

patricktoulon

un pseudo evenement Application_AfterResize

Note : 4 votes pour une moyenne de 1,25.
2 Commentaires
par
patricktoulon
, 28/06/2019 à 10h36 (624 Affichages)
bonjour a tous

juste une petite astuce pour créer un évènement AfterResize de l'application qui n'existe pas
l'évènement window_Resize ne fonctionnant qu'avec le Windows du classeur il est donc inutilisable pour la fenêtre application

cette méthode demande très peu de ressource puisque la surveillance se fait avec l'évènement on_update de la commandbars
une alternative au timer (api) ou application ontime en boucle et autre
de plus quand le update est déclenché il est non bloquant pour le reste des macros ou l'utilisation de Excel
pour l'exemple je zoom une plage définie pour la garder visible entièrement a chaque instant

a placer dans le module thisworkbook

[CODE=vba]
Option Explicit
Private WithEvents Cmbrs As CommandBars
Dim oldwidth As Double
Dim oldheight As Double
'
'evenement commandbars
Private Sub Cmbrs_OnUpdate()
With Application
.CommandBars.FindControl(ID:=2040).Enabled = Not .CommandBars.FindControl(ID:=2040).Enabled
If oldheight <> .Height Or .Width <> oldwidth Then
Application_AfterResize
End If
End With
End Sub
'
Private Sub Workbook_BeforeClose(Cancel As Boolean)
Application.CommandBars.FindControl(ID:=2040).Enabled = True
End Sub
'
Private Sub Workbook_Open()
Set Cmbrs = Application.CommandBars
End Sub
'
'
Private Sub Application_AfterResize()
Dim cel As Range
Set cel = Selection
Range("A1:J30").Select
ActiveWindow.Zoom = True
oldheight = Application.Height
oldwidth = Application.Width
cel.Select
End Sub
[/CODE]

testé sur 2007

Envoyer le billet « un pseudo evenement Application_AfterResize » dans le blog Viadeo Envoyer le billet « un pseudo evenement Application_AfterResize » dans le blog Twitter Envoyer le billet « un pseudo evenement Application_AfterResize » dans le blog Google Envoyer le billet « un pseudo evenement Application_AfterResize » dans le blog Facebook Envoyer le billet « un pseudo evenement Application_AfterResize » dans le blog Digg Envoyer le billet « un pseudo evenement Application_AfterResize » dans le blog Delicious Envoyer le billet « un pseudo evenement Application_AfterResize » dans le blog MySpace Envoyer le billet « un pseudo evenement Application_AfterResize » dans le blog Yahoo

Mis à jour 28/06/2019 à 20h57 par Arkham46 (Coloration code vba)

Catégories
Sans catégorie

Commentaires

  1. Avatar de Pierre Fauconnier
    • |
    • permalink
    Salut.

    Si tant est que cela ait une quelconque utilité de redimensionner l'application et pas uniquement la fenêtre courante, car dans les faits cela revient au même, me semble-t-il:
    • Que se passe-t-il si aucune feuille de calcul n'est active au moment du redimensionnement? => plantage;
    • Que se passe-t-il si c'est un autre objet qu'un Range qui est actif au moment du redimensionnement? => plantage;
    • Il faudra blinder le code avec une super gestion d'erreur car dès que l'on stoppera le code suite à un débogage, la variable Cmbrs sera Nothing et ton brol ne fonctionnera plus;
    • Ce truc redimensionne TOUTES les feuilles pour zoomer sur A1:L30, or il est assez rare que toutes les feuilles aient besoin du même zoom. Une approche plus réaliste consisterait à utiliser une plage nommée par feuille à l'instar de Zone_d_impression pour que chaque feuille soit redimensionnée de façon personnalisée;
    • Devoir modifier l'environnement de l'utilisateur en désactivant un bouton (même peu utilisé) pour que le brol fonctionne me semble une fantaisie de haut vol (pourquoi celui-là et pas un autre?);
    • la sélection d'une zone n'est pas sans conséquences sur le reste du code, car tu peux très bien avoir un évènement SelectionChange qui est écouté dans l'appli, et range("a1:l30).select va le déclencher, avec peut-être des conséquences non maîtrisées. Il faudrait donc court-circuiter l'évènement soit par Application.EnableEvents qui passe à False le temps du traitement et repasse à ce qu'il était avant après le traitement (avec un on error pour gérer le problème éventuel). C'est toujours un danger, et pour moi de la mauvaise programmation, que de sélectionner une plage sans que cela ne soit absolument nécessaire;
    • ...


    Je pense donc que ce code est plus dangereux et improductif qu'autre chose. Vu que Workbook_WindowResize existe, je pense même qu'il est inutile. Pourquoi Workbook_WindowResize n'est-il pas suffisant, avec bien sûr les précautions d'usage (voir certains points listés plus haut)? Et ces précautions font que c'est loin d'être simple de penser à toutes les conséquences de ce qu'on programme. Il ne suffit pas d'avoir une "idée de génie", inutile qui plus est, il faut pouvoir la mettre en oeuvre de façon professionnelle.
  2. Avatar de patricktoulon
    • |
    • permalink
    [QUOTE=Pierre Fauconnier;bt11642]Salut.

    Si tant est que cela ait une quelconque utilité de redimensionner l'application et pas uniquement la fenêtre courante, car dans les faits cela revient au même, me semble-t-il:
    [LIST][*]Que se passe-t-il si aucune feuille de calcul n'est active au moment du redimensionnement? => plantage;[*]Que se passe-t-il si c'est un autre objet qu'un Range qui est actif au moment du redimensionnement? => plantage;[*]Il faudra blinder le code avec une super gestion d'erreur car dès que l'on stoppera le code suite à un débogage, la variable Cmbrs sera Nothing et ton brol ne fonctionnera plus;[*]Ce truc redimensionne TOUTES les feuilles pour zoomer sur A1:L30, or il est assez rare que toutes les feuilles aient besoin du même zoom. Une approche plus réaliste consisterait à utiliser une plage nommée par feuille à l'instar de [I]Zone_d_impression[/I] pour que chaque feuille soit redimensionnée de façon personnalisée;[*]Devoir modifier l'environnement de l'utilisateur en désactivant un bouton (même peu utilisé) pour que le brol fonctionne me semble une fantaisie de haut vol (pourquoi celui-là et pas un autre?);[*] la sélection d'une zone n'est pas sans conséquences sur le reste du code, car tu peux très bien avoir un évènement SelectionChange qui est écouté dans l'appli, et range("a1:l30).select va le déclencher, avec peut-être des conséquences non maîtrisées. Il faudrait donc court-circuiter l'évènement soit par Application.EnableEvents qui passe à False le temps du traitement et repasse à ce qu'il était avant après le traitement (avec un on error pour gérer le problème éventuel). C'est toujours un danger, et pour moi de la mauvaise programmation, que de sélectionner une plage sans que cela ne soit absolument nécessaire;[*]...[/LIST]

    Je pense donc que ce code est plus dangereux et improductif qu'autre chose. Vu que Workbook_WindowResize existe, je pense même qu'il est inutile. Pourquoi Workbook_WindowResize n'est-il pas suffisant, avec bien sûr les précautions d'usage (voir certains points listés plus haut)? Et ces précautions font que c'est loin d'être simple de penser à toutes les conséquences de ce qu'on programme. Il ne suffit pas d'avoir une "idée de génie", inutile qui plus est, il faut pouvoir la mettre en oeuvre de façon professionnelle.[/QUOTE]

    bonjour pierre
    inutile pour toi
    quand au fait d'être généraliste(sur toute les feuilles) ca peut se régler très facilement
    cela dit dans l'exemple fourni je zoom une plage mais on peut parfaitement faire autre chose dont on aurait besoins

    interdire le redimensionnement
    interdire le déplacement
    modifier la position ,dimension d'une autre fenêtre
    etc. .etc...


    c'est cet aspect la que j'aurais voulu que tu vois

    il suffit de coder ton besoins dans le pseudo évènement comme dans les évènement existant

    [QUOTE]Vu que Workbook_WindowResize existe[/QUOTE]
    oui mais cet évènement est déclenché par le Resize du window(classeur)
    perso par exemple je me suis fait un pseudo aerosnake pour afficher deux classeurs dans 2 instances d'Excel différentes cote a cote prenant chacun la moitié de l'écran