MÉTHODE ZOOM SUR UNE FORM (ET SES CONTRÔLES)
bouv
Messages postés
1411
Date d'inscription
mercredi 6 août 2003
Statut
Membre
Dernière intervention
3 mars 2019
-
30 nov. 2006 à 09:48
mortalino Messages postés 6786 Date d'inscription vendredi 16 décembre 2005 Statut Membre Dernière intervention 21 décembre 2011 - 3 juin 2008 à 20:36
mortalino Messages postés 6786 Date d'inscription vendredi 16 décembre 2005 Statut Membre Dernière intervention 21 décembre 2011 - 3 juin 2008 à 20:36
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/40519-methode-zoom-sur-une-form-et-ses-controles
https://codes-sources.commentcamarche.net/source/40519-methode-zoom-sur-une-form-et-ses-controles
3 juin 2008 à 20:36
pas besoin en VBA, les UserForm sont dotés de la méthode Zoom.
(Me.Zoom = 120) par exemple, t'augmente la taille de 20 %
Si tu veux un exemple (mais le mieux c'est d'essayer) télécharge mon annuaire Excel :
http://www.vbfrance.com/codes/ANNUAIRE-AVEC-OPTIONS_36986.aspx
@++
3 juin 2008 à 11:11
si je comprends bien, tu avais fait ça sous VBA avant ! Tu aurais le code, svp ?
15 mai 2007 à 19:07
15 mai 2007 à 18:57
20 janv. 2007 à 23:26
Sinon, pour les coordonées, je suis (je pense) obligé de travailler avec les coordonnées d'origines, cela n'aurait pas été génant en cas "d'un seul" Zoom pendant que l'appli tourne, mais au delà, ça devient désatreux.
Je change les tableaux ^^
@++ ;)
20 janv. 2007 à 23:22
Type MESDIM
Top As Long
Left As Long
Width As Long
Height As Long
End Type
Dim MonTab() As MESDIM
après reste à voir la réelle utilité de stoquer les coordonnées, si le problème est le contrôle Line, ton test dans la boucle est déjà efficace donc...
20 janv. 2007 à 23:17
Si je travaille les données avec celles actuelles, lors du premier zoom, ça va, mais les suivantes sont faussées... :(
As-tu une autre idée ?
@++ ;)
20 janv. 2007 à 23:10
j'utilise les 4 tableaux afin de mémoriser les coordonnées et les dimensions de chaque controles, mais je vois ce que tu veux dire, pas besoin de tableaux, il suffirait de travailler avec ctl.Top, etc... sans stocker les valeurs.
Je sais plus trop pourquoi j'étais passé par là, mais avec la MAJ, j'étais ancré sur la classe collection.
Je vois ce que je peux faire de suite ;)
Pour ton ps, je vais voir si je peux trouver une solution, mais ça m'a pas l'air gagné :$
Et pour l'idée d'évolution, c'est mieux en dll, merci du conseil !
@++ ;)
20 janv. 2007 à 22:57
bien mieux maintenant.
un choix étrange pourtant : dans la classe principale tu utilises 4 tableaux, pourquoi?
un tableau de type sera beaucoup moins lourd.
et sans oublier de le détruire dans le Terminate ;)
ps : dommage néanmoins que seuls les contrôles intrinsèques soit pris en compte...
idée d'évolution : transformer ton projet en dll ou ocx
@+
17 déc. 2006 à 00:44
@++
16 déc. 2006 à 05:06
Prochaine : prise en compte de la taille du texte + modif pour le type Line (désolé, mais là ce n'était pas ma priorité)
++
30 nov. 2006 à 17:59
Oui, ça résume tout, j'ai posé une question pour le ParamArray (en fait, c'était évident) mais je vais faire avec ta proposition :
TaClass.AddException MonControl1
Tant qu'à utiliser une Class, autant exploiter les possibilités !
(je sais où regarder, j'ai une excellente Class en ma possession, qui me servira d'exemple) ;)
Concernant ton Ps, c'est aussi une excellente idée, je vais regarder ça ce soir
Merci ;)
++
30 nov. 2006 à 17:45
les précédents commentaires résument tout.
"En cas, je rajouterai un paramêtre "ParamArray" (...)", pas top, plutôt gérer un tableau ou une collection, pour donner quelque chose du genre TaClass.AddException MonControl1
et en effet, c'est dommage pour la taille de la typo
ps : tu gères le top left (indispensable) pour les contrôles, peut-être proposer en option aussi de recadrer la fenêtre...
(surtout dans la cas où le resize est effectué suite à un changement de résolution)
bon courage @+ ;)
30 nov. 2006 à 15:32
En fait c'est vrai que dans la class j'évite le redimensionnement de la VScroll, elle devrait être géré 'depuis' la Form.
En cas, je rajouterai un paramêtre "ParamArray", pour que le developpeur puisse mettre en paramètre depuis l'appel de la sub des contrôles à ne pas toucher, et ça éviterai de toucher à la class.
Je n'avais pas compris ton histoire de VScroll, mais je vois où tu veux en venir (je ne suis réveillé que depuis 2h, le temps que ça monte au cerveau).
Remarque judicieuse et je t'en remercie. ;)
Du coup on ne parlera plus de VScroll dans la class, et la procédure, deviendrai (en gros) :
Call PropertyZoom.Zoomed(Me, VScroll1.Value, VScroll1)
J'y travaille ;)
@++
30 nov. 2006 à 15:19
Dans ce cas si tu ne veux pas faire de zoom sur le VScroll il te faut la aussi récupérer son type car si depuis mon projet je continue à utiliser un VSCroll et qu'il ne s'appelle pas VScroll1, il sera redimensionner avec les autres contrôles. en revanche pour ce qui est des appels de procédures et l'utilisation d'une classe, j'avais bien compris...
Ce que je voulais dire c'est qu'à mon avis une classe ne devrait pas avoir de "référence" ou de limitation par rapport à un projet, voila tout. hors en mettant une condition sur le nom d'un contrôle tu peux tomber dans le cas ou la condition soit juste mais pas désirable. (ce qui rejoint aussi la gestion d'erreur pour l'objet Ligne)
Qu'en penses tu?
@+
Julien
30 nov. 2006 à 14:59
Bouv : oui, bien vu, je verrai aussi pour l'évènement resize.
(j'étais parti du VBA, donc, le UserForm n'étant resizable, je n'y ai pas pensé)
Concernant ta source, je vais y jeter un oeil ce soir en rentrant du boulot. ;) (merci)
Julien : 1/ pour la simple et bonne raison que je connais pas tout les types des controles et surtout, il y en a que je n'ai pas testé (peut-être car je ne les ai pas) donc je trouvais que la gestion d'erreur était plus simple. A voir !
Je testerai ta méthode et verrai la plus pratique ;)
2/ Utilisable ~que~ dans ce projet ??
Beh non, t'importes la classe dans ton projet, après dans ta form, il faut instancier l'objet par le nom de ma classe puis appeler les 2 méthodes (sub dans la classe)
C'est juste que j'ai mis l'appelle de la sub dans l'évènement VScroll_Change pour la modif du zoom (en exemple), mais il faut bien, tôt ou tard, que tu appelles cette sub avec la valeur (à défaut d'être géré par un contrôle)
Depuis n'importe quelle Form de ton projet :
Public PropertyZoom As New FormZoomed_cls
Puis, par exemple, dans le load :
Call PropertyZoom.Ini_Classe(Me)
Call PropertyZoom.Zoomed(Me, 200) ' pour 200%
C'est sûr qu'en Module normal ça passe, mais je préfèrais passer par une classe, car je compte la modifier et rajouter des possibilités.
@++ ;)
30 nov. 2006 à 10:11
Pas mal. Mais:
1) Pourquoi se servir d'une erreur pour déduire le type de contrôle:
- If Err.Number = 438 Then ' gestion des Lines
Lorsque tu pourrais utiliser:
If TypeOf ctl Is Line Then
'Gestion des lines
Else
'Gestion des autre contrôle
End If
Car après tout peu être que les lignes ne sont pas les seuls contrôles ne possèdant ni top, height... (bien que je n'en connaisse pas)
2) Pourquoi faire une classe qui n'est utilisable que dans ce projet (bien sûr ensuite c'est à celui qui veut l'utiliser de l'adapter ça je comprend bien) Mais alors "Pourquoi une classe".
Voilà,
Aller Bonne prog.
@+ Julien
30 nov. 2006 à 09:48
Sinon il y a quelques problèmes de superposition quand on réduit trop. La problème ne peut pas vraiment être reglé étant donnée que certain controle (ex: TextBox, ComboBox) ont une taille verticale minimum. La seule solution est de bien calculer son coup et de limiter le zoom arrière avant que cela ne se produise.
Je m'étais déjà penché sur le sujet, jette un coup d'oeil ici :
http://www.vbfrance.com/codes/GESTION-FORMS-OCX-V2_34146.aspx
Cela pourra peut être te donner des idées.