|
Publicité ' | ||||||||||||||||||||||||
|
|
#1 | ||
|
Membre éclairé
![]() Inscription : septembre 2006 Messages : 544 ![]() |
Hello,
Voici un code à placer dans un module... Il permet de détecter la résolution actuelle de l'écran et de redimensionner en fonction de la résolution de développement. Ca existait déjà, les petits + sont : + Gestion des contrôles spéciaux : Onglets, boutons radios, listes, sections... + Lisibilité améliorée des polices (par un léger agrandissement à prendre en compte lors de la création) + Gestion des résolutions plus élevées, mais aussi plus petites + Gestion des contrôles ActiveX (Comme le calendrier. Attention toutefois, les polices de celui-ci étant intégrées, il arrive que pour certaines résolutions, le texte de la date disparaisse s'il est trop petit, comme le Calendrier, par exemple. mais c'est à prendre à compte lors de la conception)... Voici le code. Je suis ouvert à toutes les remarques et à tous les bugs Code :
Test effectués (Access 2003 et XP) : Boutons radios, cases à cocher, onglets avec plusieurs pages (contenant elles mêmes d'autres objets spéciaux), images, Calendrier ActiveX, et puis les contrôles standards : Boutons, listes, étiquettes... Bogues constatés : Problème de redimensionnement des sections, colonnes des listes non redimensionnées... Améliorations à venir : + Gestion de la largeur des colonnes des listes. Les listes se mettent aux bonnes dimensions, mais pas les colonnes. Elles restent fixent par rapport aux cm entrès lors de la conception... + Prise en charge complète des sections... Le 21.07.2007 : Prise en charge des listes et des sections, simplification du code Test effectués (Access 2003 et XP) : Tous les tests précédents ainsi que des tests avec différentes sections et différentes listes (fixes, déroulantes) Le 26.07.2007 : Essai prise en charge des formulaires "feuille de données" + quelques 'tites modifs du code... Nouveaux essais (Access 2003 et XP) : Concluants pour le 1er redimensionnement, mais les colonnes ne reprennent pas leurs dimensions originales... Le 27.07.2007 : Prise en charge des formulaires "feuille de données" Nouveaux essais concluants ! Petit bug constaté : Lorsqu'on change de résolution, il faut ouvrir deux fois le formulaire. La première fois, les colonnes sont invisibles, pourtant unr boite de message me certifie que celles-ci sont de largeur > 0... Je ne sais pas d'où ça vient... Ceci dit, je pense qu'il faudrait pousser plus loin la recherche et affecter à chaque colonne, non pas une dimension, mais un pourcentage en fonction de la largeur (moins la largeur de l'ascenseur...)................. Tests à venir : Essais avec le RunTime... Merci à tous pour vos conseils...
__________________
Il est plus important de chercher que d’avoir trouvé. (André Siegfried) Abusez de la touche F1, de la FAQ, de la Recherche... et aussi du Résolu et du MERCI... |
||
|
|
10
|
|
|
#2 |
![]() ![]() |
Bonjour
Il faudrait essayer de tester evec des composants non standard qui sont souvent utiliser sous Access (DtPicker, Calendrier, et...) Starec |
|
|
00
|
|
|
#3 |
|
Membre éclairé
![]() Inscription : septembre 2006 Messages : 544 ![]() |
Ok, je note...
Edit: Pour le calendrier ActiveX, aucun problème... Il se redimensionne, j'ai juste corrigé au niveau du redimensionnement de la police (ce contrôle n'en ayant pas). Je n'ai jamais utilisé le "dtPicker" par contre... je le trouve où ?
__________________
Il est plus important de chercher que d’avoir trouvé. (André Siegfried) Abusez de la touche F1, de la FAQ, de la Recherche... et aussi du Résolu et du MERCI... |
|
|
00
|
|
|
#4 |
|
Membre éclairé
![]() Inscription : septembre 2006 Messages : 544 ![]() |
Hello,
Je viens d'apporter quelques corrections à mon code de départ, notamment la gestion des onglets... J'ai également mis quelques annotations en plus... PS : J'ai préféré corriger le code du début de mon premier messge afin qu'il n'y ait pas trop de codes ou trop de versions dans ce message... Si j'ai mal fait, n'hésitez pas à me corriger !! Bonne journée à tous ! (euh... sous la pluie ici............)
__________________
Il est plus important de chercher que d’avoir trouvé. (André Siegfried) Abusez de la touche F1, de la FAQ, de la Recherche... et aussi du Résolu et du MERCI... |
|
|
00
|
|
|
#5 | ||
|
Membre habitué
![]() Inscription : septembre 2005 Messages : 310 ![]() |
Bonjour à tous !
Ce sujet a l'air super intéressant ! J'ai donc tester le code, je suis sous Access 97. Sur un Form_open j'ai donc indiqué proResolution Me et là j'ai une erreur à l'ouverture du formulaire : "Erreur de compilation, sub ou fonction non définie" sur Code :
|
||
|
|
00
|
|
|
#6 | ||
|
Membre éclairé
![]() Inscription : septembre 2006 Messages : 544 ![]() |
Hello,
Oui, tout à fait, et c'est normal !!! C'est une gestion d'erreur perso ! Remplace ce morceau de code par : Code :
Attenton à une chose : Je ne sais pas si c'est compatible avec des versions antérieures à Access 2003...
__________________
Il est plus important de chercher que d’avoir trouvé. (André Siegfried) Abusez de la touche F1, de la FAQ, de la Recherche... et aussi du Résolu et du MERCI... |
||
|
|
00
|
|
|
#7 |
|
Membre habitué
![]() Inscription : septembre 2005 Messages : 310 ![]() |
Merciiiiiiiiiiii :-)
Sauf que now j'ai une erreur Erreu de compilation, Etiquette non définie sur Resume Sortie_proResolution alors que j'ai bien plus loin Par avance merci ;-) @+ |
|
|
00
|
|
|
#8 |
|
Membre éclairé
![]() Inscription : septembre 2006 Messages : 544 ![]() |
Hello,
Je ne connais pas Access 97. Mais comme de toute façon, il n'y a pas de code dans la section "sortie", tu n'as qu'à remplacer Resume Sortie_proresolution par Exit Sub. Comme ça, pas besoin de faire un retour sur une section qui ne sert qu'à quitter la procédure...
__________________
Il est plus important de chercher que d’avoir trouvé. (André Siegfried) Abusez de la touche F1, de la FAQ, de la Recherche... et aussi du Résolu et du MERCI... |
|
|
00
|
|
|
#9 |
|
Membre éclairé
![]() Inscription : septembre 2006 Messages : 544 ![]() |
Hello,
Voilà... Je viens d'apporter une nouvelle modif à mon code... Cette fois-ci, les onglets, les listes, les contrôles, les sections, etc... sont normalement pris en compte... Si l'envie vous dit de tester tout ça... Je suis preneur des bogues à corriger !!! Bon week-end à toutes et tous !!!
__________________
Il est plus important de chercher que d’avoir trouvé. (André Siegfried) Abusez de la touche F1, de la FAQ, de la Recherche... et aussi du Résolu et du MERCI... |
|
|
00
|
|
|
#10 |
![]() ![]() |
Bonjour Noawsen,
Premières constatations. Access XP, Windows XP pro. Pas de bugs, compile parfaitement. Un formulaire développé en 800 x 600 (j'ai donc changé les constantes) affiché en 1024 x 768). Ce formulaire est affiché sans barre d'état, mais avec une barre de menus personnalisée. Dimension "limite", puisqu'il fait 21cm de largeur, sur 13.5 de hauteur, sans bordure. Propriété auto centrer à Oui L'affichage n'est pas tout à fait correct dans la mesure où il est mal positionné en haut à gauche (à vue d'oeil, je dirai 2cm trop à droite et 1.5cm trop bas). J'ai donc les barres de défilement verticale et horizontale, alors qu'il devrait occuper uniquement la quasi-totalité de l'écran. Ton ratio de redimmensionnement est peut-être un "poil" trop généreux... Mais c'est peut-être aussi un peu trompeur. Comme il est trop grand, la propriété Auto centrer ne fait peut-être pas correctement son boulot ! Un contrôle un peu particulier, un treeview, se redimmensionne parfaitement. Pour le reste de ce que je vois... Chapeau... C'est plus que prometteur...Domi2
__________________
Vous avez des montres, nous avons le temps ! (citation attribuée à L.-S. Senghor) Ici, on ne perd pas de temps ! On en passe... Ce message (ou un autre) vous a aidé ? Votez pour lui avec
|
|
|
00
|
|
|
#11 | ||||
|
Membre éclairé
![]() Inscription : septembre 2006 Messages : 544 ![]() |
Hello,
Citation:
(Elle est dans les sources, il me semble... je ne crois pas l'avoir retouchée...)Citation:
Ce ratio est donc là pour rendre les polices visibles quand on descend en résolution... A tester pour le diminuer au maximum... Citation:
J'avais pas testé !Citation:
Merci de ton aide, c'est très sympa !!! Je vais mijoter tout cela ce dimanche... J'aurais l'esprit plus frais lundi... et peut-être un peu moins mal à la gorge (dfyzefy ygfey fzyeff de temps !!!) Bon week-end !!! Enfin... bon dimanche...
__________________
Il est plus important de chercher que d’avoir trouvé. (André Siegfried) Abusez de la touche F1, de la FAQ, de la Recherche... et aussi du Résolu et du MERCI... |
||||
|
|
00
|
|
|
#12 | |
![]() ![]() |
Cordial et matinal bonjour,
Citation:
![]() Ca fonctionne "pil-poil"... Donc pas de problème de redimmensionnement... J'ai bien regardé les contôles (étiquette et texte) où les textes étaient "limites". Ils sont à peine plus "courts" et ne sortent donc pas des contrôles, c'est ok. Les zones de listes, les boutons, les contrôles images, le treeview, ça à l'air ok. Les onglets, ça a l'air parfait. Par contre, pour le groupe d'options, j'observe un léger décalage (voir photo). Les sous-formulaires en mode continu, ça à l'air tout bon. En mode feuille de données, reste la largeur des colonnes. Et un contrôle un peu particulier, les cases à cocher. J'ai de la peine à dire si elles se redimmensionnent. Je dirais non ! Edit : Après vérification, elle ne semblent pas redimmensionnable et c'est pris en compte dans ton code... Ca passe par ailleurs très bien à l'oeil, pas de soucis donc ! Je vais essayer de faire le test inverse (1024x768 ==> 800x600), mais c'est sans garantie aujourd'hui. A mon avis, tu es bientôt bon pour la postérité Domi2
__________________
Vous avez des montres, nous avons le temps ! (citation attribuée à L.-S. Senghor) Ici, on ne perd pas de temps ! On en passe... Ce message (ou un autre) vous a aidé ? Votez pour lui avec
|
|
|
|
00
|
|
|
#13 | |||||
|
Membre éclairé
![]() Inscription : septembre 2006 Messages : 544 ![]() |
Hello !!!
Citation:
Citation:
Citation:
Citation:
Citation:
__________________
Il est plus important de chercher que d’avoir trouvé. (André Siegfried) Abusez de la touche F1, de la FAQ, de la Recherche... et aussi du Résolu et du MERCI... |
|||||
|
|
00
|
|
|
#14 |
![]() ![]() |
Bonjour
Pour info pour la largeur des colonnes en mode feuille de données il faut utiliser : ColumnWidth et pour la hauteur RowHeight (s'applique à toutes les lignes). Starec |
|
|
00
|
|
|
#15 |
|
Membre éclairé
![]() Inscription : septembre 2006 Messages : 544 ![]() |
Hi,
Merci... Bien noté !!!
__________________
Il est plus important de chercher que d’avoir trouvé. (André Siegfried) Abusez de la touche F1, de la FAQ, de la Recherche... et aussi du Résolu et du MERCI... |
|
|
00
|
|
|
#16 |
![]() ![]() |
Bonjour,
Test 1024 x 768 ==> 800 x 600. Ca ne commence pas trop bien. J'utilise de nouveau un formulaire "limite" de 26.8 cm de largeur et de 18 cm de hauteur (sans la barre d'état). Il ne rentre pas dans la fenêtre... De pas grand chose, mais il ne rentre pas. J'ai bien utilisé la fonction de centrage et fait également le test avec un MoveSize. Domi2
__________________
Vous avez des montres, nous avons le temps ! (citation attribuée à L.-S. Senghor) Ici, on ne perd pas de temps ! On en passe... Ce message (ou un autre) vous a aidé ? Votez pour lui avec
|
|
|
00
|
|
|
#17 |
|
Membre éclairé
![]() Inscription : septembre 2006 Messages : 544 ![]() |
Hello,
En fait, il y a plusieurs problèmes intrinsèques à la conception lorsqu'on descend en résolution... Par rapport au code écrit, soit on supprime le ration de redimensionnement et dans ce cas, on aura exactement la même taille quelle que soit la résolution(mais on risque d'avoir un problème au niveau des polices et des tailles de contrôles : Soit les polices sont illisibles, soit elles sortent du cadre), soit on fait des formulaires un peu plus petit afin de prendre en compte le redimensionnement par arpport au ration, ce que je préconise dans mon code... Malheureusement, Access ne prenant pas en charge le redimensionnement, j'ai fait le choix de faire des formulaires plus petits qui ne dépasseront pas de l'écran... Une solution possible sans utiliser de facteur d'agrandissement est d'utiliser des polices dont la taille est supérieure à 10. En résolution plus petite, elles devraient rester lisibles... Dans tous les cas, c'est donc un choix qui reste à faire à la conception... Je n'ai pas d'autre solution sous la main...
__________________
Il est plus important de chercher que d’avoir trouvé. (André Siegfried) Abusez de la touche F1, de la FAQ, de la Recherche... et aussi du Résolu et du MERCI... |
|
|
00
|
|
|
#18 |
|
Membre éclairé
![]() Inscription : septembre 2006 Messages : 544 ![]() |
Bonsoir...
Voici un nouveau bout de code... Et la, j'aurais besoin de toute l'aide disponible pour un 'tit problème que je ne comprends pas... La largeur des colonnes se redimensionne bien à la lecture du formulaire... Elle se redimensionne également à la fermeture, car si j'affiche leur largeur dans une MsgBox, je vois bien qu'elle s redimensionne... Mais le problème, c'est que la nouvelle largeur (celle d'origine, donc) ne s'enregistre pas... Ce qui fait qu'à la deuxième ouverture, les colonnes se redimensionnent en fonction du premier redimensionnement et donc s'élargissent encore + et + et ++++; jusqu'à un dépassement de capacité... J'ai pasé un bout de temps dessus, mais je ne comprends pas... La solution serait éventuellement de programmer les largeurs des colonnes dans le Form_Load ou Form_View du formulaire feuille de données... Comme ça, plus besoin de redimensionner à la fermeture, mais j'aurais préféré qqch de plus automatisé... Je n'ai pas encore testé avec plusieurs sous-forms en feuille de données, mais la aussi, je me demande si ça ne va pas poser quelques problèmes... Je vais voir tout ça... A bientôt...
__________________
Il est plus important de chercher que d’avoir trouvé. (André Siegfried) Abusez de la touche F1, de la FAQ, de la Recherche... et aussi du Résolu et du MERCI... |
|
|
00
|
|
|
#19 |
|
Membre éclairé
![]() Inscription : septembre 2006 Messages : 544 ![]() |
Voilà... Je continue mon monologue !!!
Je viens de mettre le code qui permet de redimensionner également les colonnes des formulaires feuille de données (avec un 'tit bug que je ne comprends pas, tout est écrit dans le 1er message)... Ce n'est pas parfait, je pense qu'il faudrait écrire une 'tite fonction placée dans le Form_Open des formulaires feuille de données afin de gérer la largeur des colonnes en pourcentage... Ou mieux, d'écrire la largeur des colonnes en vba (une ligne pour chaque colonne)..... Mais, bon, ça à déjà le mérite d'être efficace à 95%... ........ Ouai, ouai, ouai... j'en vois déjà qui disent :"Mouiiiii, et les 5% ??? Bref, je vous laisse juger, essayer, critiquer, m'insulter, et même me bannir de ce forum !!!!
__________________
Il est plus important de chercher que d’avoir trouvé. (André Siegfried) Abusez de la touche F1, de la FAQ, de la Recherche... et aussi du Résolu et du MERCI... |
|
|
00
|
|
|
#20 |
|
Invité de passage
![]() |
salut noawsen,
et donc il est où le code final et parfait je le vois pas tu peux pe le joindre ici pour l'utiliser stp? |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com