Discussion :

[bigboomshakala]

bonsoir,

en java et avec Qt, on a la possibilité de définir des gestionnaire de mise en forme (layout) qui prennent en charge le positionnement (et le repositionnement le cas échéant : redimensinonement de la fenêtre...) des composants d'interface.

est-ce que ça existe aussi avec les MFC ou la place des composants d'une interface ne peut être que statique?

merci

[farscape]

Salut,
Effectivement ça n'existe pas en natif dans les MFC ,
Mais ce n'est pas très compliqué à mettre en place .
le traitement est a faire au niveau de :
la Mainframe pour l'emplacement de la fenêtre d'application.
de la MDIChild pour les fenêtres de type view .
et sur les Dialogues.

Personnellement cette fonctionnalité est incluse dans ma librairie par redéfinitions des classes de bases citées.

[bigboomshakala]

salut,

merci, il me semblait bien que je n'avais jamais entendu parler de layout en MFC dans les bouquins VC++ et sur le forum.

tu pourrais donner un exemple de layout perso dans la FAQ

merci

[farscape]

salut,
regarde ce post:
http://www.developpez.net/forums/vie...694412#1694412

[bigboomshakala]

j'ai vu j'ai vu, merci.

ce n'était pas tout à fait ce que j'avais en tête. je voulais parler de layout pour gérer le repositionnement des boutons, edit... lorsque l'utilisateur redimensionne sa fenêtre.

en java on peut appliquer un layout sur la frame d'une fenêtre.
par exemple le FlowLayout qui permet, si ma fenêtre contient 3 boutons alignés centrés dans la fenêtre :
- de garder les boutons centrés si on redimensionne la fenêtre
- passer les boutons sur plusieurs lignes si la fenêtre est trop étroite pour qu'ils puissent tous tenir sur une ligne

avec Qt il y a également des layout qui se charge d'aligner les composants, de dimensionner la fenêtre pour coller parfaitement à son contenu...

avec les MFC, ce mécanisme n'existe pas a priori. les composants ont une place fixe. si on fait une boite de dialogue d'une certaine taille :
- quand on l'agrandit, une partie de la fenêtre est vide
- quand on diminue sa taille, une partie des composants est masqué
et pour réaliser l'interface on doit passer par l'éditeur d'interface et positionner les composants à la main.

[farscape]

il existe des implementations pour gerer ça au niveau des fenetres ,
permettant d'appliquer des changements dynamique au niveau des Dialogbar ou Formview/Dialog.

mais rien de standard il est vrai ...

[r0d]

rien de standart... exact, malheureusement. Je me demande comment ils ont fait, les gars qui ont programmé Visual MainWin (cf ce thread )?

D'ailleurs, je me suis pris la tête quelques jours là-dessus. J'ai finalement décrété que tous les utilisateurs de mon soft seront en 1024*768!!!

Le developpeur a toujours raison, ce sont les utilisateur qui sont trop niais

[bigboomshakala]

J'ai finalement décrété que tous les utilisateurs de mon soft seront en 1024*768!!!

lol, j'ai fait ça pour l'appli que j'ai développé en stage.
au début c'était involontaire, je travaillais en 1200*(...?) ou plus, je ne me souviens plus (un pur écran géant !). c'est quand j'ai fait tourné l'appli chez moi (1024*768) et que l'appli a pris presque toute la fenêtre que j'ai pensé à la résolution de l'écran.

mais bon je me suis dis tant pis! au début du stage on était pas sur que l'appli était faisable, là je l'ai réalisé. alors la taille du bazar se sera éventuellement à reprendre par quelqu'un d'autre si l'appli doit tourner sur un écran dont la résolution est trop petite ou trop grande.

[r0d]

Pour moi, c'est un problème épineux. En effet, si on utilise 3 boutons et un combo, on peut facilement paramétrer tout ça. Mais quand on a (ce qui est mon cas):
1/ un nombre de boutons indéterminés
2/ un custom ctrl dont on ne connait pas réellement le contenu
3/ des scrollbars dans tout les sens
4/ des bitmaps qui peuvent également changer de taille
5/ des check, des combos, des edits et des statics tout plein partout
Et bien, je prends peur rien que de penser à tout ce à quoi il faut penser pour bien penser l'IHM (si vous voyez ce que je veux dire )

Si je me souviens bien, les Layout de QT se présentent comme des petits ressorts rouges? Si c'est ça, c'était vraiment trop pratique! Je confond peut-être avec GTK...

[farscape]

je vous prerare une petite classe template ...

[bigboomshakala]

le ressort bleu de Qt est un Spacer. il sert à insérer un espace libre. ainsi les boutons à côté sont poussés vers la droite
en rouge, les layout (horizontaux ici).



cool Farscape

[farscape]

re,
voir mon dernier post :
http://www.developpez.net/forums/vie...59308&start=90

votre avis ?

[bigboomshakala]

aah il est bon!

juste un défaut si j'osais... ça ne gère pas le chevauchement des contrôles. suivant comment on dimensionne la fenêtre, le static est recouvert par les boutons. je ne sais pas si on peut y remédier. ou alors interdire de redimensionner la fenêtre en-dessous de la somme des dimensions minimales des composants (comme en java finalement).

mais chapeau pour la réactivité! tu avais déjà un template proche de celui-ci sous le coude, ou c'est tout fait main aujourd'hui?

[farscape]

aah il est bon!

juste un défaut si j'osais... ça ne gère pas le chevauchement des contrôles. suivant comment on dimensionne la fenêtre, le static est recouvert par les boutons. je ne sais pas si on peut y remédier. ou alors interdire de redimensionner la fenêtre en-dessous de la somme des dimensions minimales des composants (comme en java finalement).

mais chapeau pour la réactivité! tu avais déjà un template proche de celui-ci sous le coude, ou c'est tout fait main aujourd'hui?

pas sous forme de template mais tout fait main aujourd'hui quand même ,
On peut toujours améliorer le bazar, les bases sont établies
il reste a trouver les bonnes régles .

[bigboomshakala]

[RESOLU]

[farscape]

quoi tu as modifié pour tenir compte des collisions ?

[r0d]

je n'ai malheureusement pas le temps de tester ton template aujourd'hui . Demain peut-être. En tout cas,

[farscape]

le post a ete mis a jour pour le support des: CDialog / CFormView / CDialogbar.

[bigboomshakala]

quoi tu as modifié pour tenir compte des collisions ?

ouloulou que nenni. j'ai mis [RESOLU] pour indiquer où le post a été résolu

le post a ete mis a jour pour le support des: CDialog / CFormView / CDialogbar.

[r0d]

kool, j'ai réussi à terminer mon boulot plus tôt que prévu :o) J'ai donc un peu de temps pour tester ta classe. Seulement, je suis assez nul avec visualC++/MFC , alors j'aurais besoin d'un coup de pouce:

Je vais tester sur un CDialog, c'est avec ça que je suis le plus à l'aise (enfin, que je galère le moins):
1/ Puis-je créer un projet classique, basé sur une boite de dialogue, ou dois-je faire autrement?
2/ J'ai ma CDialog principale TestLayoutDlg, puis-je la faire hériter de ta classe CTplLayout (aulieu de CDialog)? OU alors, dois-je créer une nouvelle DlgBox?
3/ Pourquoi est-ce que tu met tout ensemble (déclaration/définitions)? Ne vaut-il pas mieux utiliser 2 fichiers (.h, .cpp)?

merci