Discussion :

[patricktoulon]

Il s'agit de SON classeur.

oui et il sagit de mon module redimcontrols simplifié qui entre parentheses a éte repris dans le monde entier et sur divers site
si garlimù ne repond plus pause toi la question pourquoi ou pas comme tu veux

[Invité]

Bonjour,
Quand on utilise des formulaire dans Excel, on les dessine dans la plus mauvais définition de Windows!

Si on veut chiader ses formulaires on passe en .net qui fait ça en natif!

[unparia]

Bonjour Robert
Ce qui est en fait ici à reconsidérer, c'est la démarche elle-même, sa philosophie, etc ...
Et traiter de surcroît une telle démarche par un redimensionnement peut dans de nombreux cas conduire aux mésaventures rapportées par Garlim.
Redimensionner en respectant non pas les proportions des choses redimensionnées, mais celles du rectangle où on veut les afficher relève de ce que je m'abstiens de nommer.

Voilà maintenant Garlim dans l'embarras et je vois vraiment mal comment qui que ce fût pourrait l'en sortir (j'entends par là : de manière fiable et pérenne, entendons par là en prenant en compte tant une évolution de son userform qu'un éventuel futur changement d'écran)

[Invité]

Bonjour jacques,
Oui il y a plus de code pour maintenir les proportions du usf que pour gérer les actions menées par celui ci!

Le parfait est l'ennemi du bien!

La.semaine dernière j'ai télécharger la version gratuite de Visual studio 2017 pour test et elle gère ça super bien les contrôles s'adapte au redimensionnement du usf à la résolution de l'écran ainsi que sa taille!

[unparia]

Oui, Robert

On peut cependant atteindre les mêmes résultats (et pas d'autres "fantaisistes et déformants") avec ce qu'offre VBA/Excel, à moindres frais, si l'on sait garder les pieds sur terre et s'en tenir à la seule raison, qui écarte toute démarche s'appuyant sur un "redimensionnement", au profit d'un autre principe : celui d'un travail sur un "miroir homothétique" qui, lui, n'intervient à AUCUN MOMENT ni sur les positions, ni sur les dimensions, ni sur les tailles de polices de caractères, etc ...
Mais même "à moindre frais", le jeu (au demeurant principalement ludique) n'en vaut pas la chandelle (Excel est un tableur, pas une "vitrine").
Bon dimanche

[unparia]

Je parlais plus haut de l'embarras dans lequel se trouve maintenant Garlim.
Je l'expose donc :
Il suffit de regarder (les images montrées) son userform pour comprendre ce qui le conduit à vouloir utiliser la totalité ("full screen") de l'écran -->> son userform est plein comme un oeuf.
Les objets qui y sont contenus pourraient bien évidemment être "rabotés" pour occuper moins d'espace, mais à quel prix ? --->> interface difficilement "lisible" et lisibilité des "textes" encore moins bonne du fait de la nécessité alors induite de diminuer toutes les tailles de polices utilisées.
Rempli, donc, comme un oeuf, il ne peut que se trouver confronté aux limites évidentes d'un "redimensionnement" lui-même confronté à certaines "non-élasticités" (lire ce que j'en ai dit plu haut).
Comment se sortir d'un tel dilemme ? --->>
- soit Patrick trouve la solution "magique" universelle (correction de son "outil" de "redimensionnement"). Et elle est tout simplement impossible avec la philosophie même de son outil.
- soit Garlim repense totalement son interface

Et il vaut mille fois mieux qu'il en prenne conscience le plus tôt possible. (Il a déjà assez perdu te temps comme cela). L'honnêteté n'est seulement une qualité; c'est une nécessité.

Amitiés à tous

[Invité]

Bonjour,

Personnellement, je n'ai jamais tenté ce genres d'aventure, je m'en sent incapable! Mais je félicite Patrick de tenter le coup.

Pour moi il est impératif d'avoir une méthode générique qui reçoit le usf et via des modules de classe instancie une image de chaque contrôle et en fonction du redimensionnement du usf redimensionne le contrôle!

Il faut noté qu'il est impossible de descendre en dessous dune certaine taille ni monté au delà d'une autre!

méthode_générique =Me

[patricktoulon]

re

Il faut noté qu'il est impossible de descendre en dessous dune certaine taille ni monté au delà d'une autre!

oui robert c'est evident d'autant plus que de ce fait il faut laisser une marge de tout cotés les bordures etant le principal probleme de l'incohérence du resize
chez moi je le prevois et ca foncionne tres bien
comme je l'ai deja dis aussi pour le font ca reste aprosimatif
on ne peut bien evedement pas tout faire mais ma solution simplifié fonctionne si on respecte ses regles

[unparia]

mais ma solution simplifié fonctionne si on respecte ses regles

Pour mémoire et sans vouloir mettre de l'huile sur le feu (le propos est de rester les pieds bien sur terre) :

Question, maintenant : Est-ce à l'application, de s'adapter à un "outil", ou à l'outil, de s'adapter à l'application ? (question existentielle).

[unparia]

Ceci étant dit :
Si à la fois :
- les conditions sont réunies (j'entends par là le calme indispensable)
- on veut bien ne pas ensuite intervenir sur le code que j'écrirais (on pourra le commenter, le critiquer au besoin, mais en aucun cas le modifier)
- on veut bien s'en tenir au raisonnable et à la logique (j'entends pas la ne toucher EN AUCUN CAS aux dimensions, positions, etc ... des objets et des polices de caractères, qui doivent garder dans tous les cas leurs proportions, telles que décidées par le développeur)

Je veux bien faire un travail en deux temps :

temps 1 : afficher le userform construit par l'utilisateur de sorte à ce que :
---- il occupe la plus grande surface possible de son écran tout en agrandissant/diminuant les images des objets qu'il contient, mais sans en modifier ni les dimensions ni la position. Par la plus grande surface possible, entendre : soit la totalité de la largeur, soit celle de la hauteur, l'autre dimension étant, elle, ajustée à son maximum proportionnel possible.
---- toutes les proportions des objets présents restent rigoureusement celles décidées par le développeur

Temps 2 : même principe fondamental que ce qui est exposé en "temps 1" en ce qui concerne les dimensions, positions et proportions des objets.
La différence sera dans la répartition des images à l'écran de ces objets, sans toucher aux objets eux-mêmes.
-- le but final ? occuper cette fois-ci non la plus grande surface possible, mais la totalité de la surface de l'écran, tout en gardant les proportions de chaque objet affiché.

Je m'efforcerai de développer cet outil sans faire appel à des fonctions de l'Api de Windows, quitte à augmenter le nombre de lignes de code (ce n'est pas leur nombre, qui fait la qualité d'une application). Dans le pire des cas (si vraiment inévitable), d'en réduire le nombre à une ou deux au maximum.

Il va s'agir là d'un travail minutieux et d'un mécanisme qui nécessiteront beaucoup de temps et d'attention. On me verra dans ces conditions très peu sur ce forum pendant toute la durée de ce travail et des tests divers et variés qui devront nécessairement être conduits pour tout vérifier. Les tests (ils sont inévitables et indispensables) eux-mêmes prendront au moins autant de temps que celui qui me sera nécessaire pour développer entre deux parties de pêche (qui restent de très loin prioritaires )

Bonne nuit

EDIT : je viens de relire ce message de bon matin et me demande si tous ses passages en auront été compris par tous.

Une explication, donc, si nécessaire, pour ceux d'entre vous qui se poseraient des questions :

Il y a un distinguo fondamental (distinguo que j'ai eu l'occasion d'évoquer à plusieurs reprises - certaines assorties d'un dessin commenté) à faire et bien comprendre entre :
- un objet, ses dimensions, sa position à l'écran et ses proportions (qui restent ceux définis par l'utilisateur et ne sont donc en aucun cas modifiés par l'outil)
et
- la représentation (affichage homothétique) de cet objet à l'écran -->> une image de l'objet qui, elle et elle seule, est agrandie/réduite/déplacée, sans toucher à l'objet lui-même

On est là tout simplement dans une démarche d'un tout autre type, n'ayant rien en commun avec celle d'un "redimensionnement".