Discussion :

[ClaudeBg]

Bonjour,

Dans une application MDI dont la MDI dispose d'une barre d'outils sur plusieurs rangées, si j'ajoute une fenêtre fille, celle-ci se place en coordonnée 0,0, et sa barre de titre est masquée par la barre d'outils.

De même, un utilisateur peut très aisément déplacer la fenêtre fille sous la barre d'outils, il lui est alors impossible de la récupérer s'il lâche le bouton de la souris à ce moment car il n'a plus aucun moyen pour la déplacer.

Pourquoi la zone active de la fenêtre MDI ne prend-t-elle pas en compte la présence de la barre d'outils? Ai-je oublié quelque chose?

Y-a-t-il un moyen simple de bloquer ces déplacement sans ajouter tout un tas de tests softwares, d'autant que bloquer la position "top" en s'abonnant à LocationChanged induit des flashes à l'écran vraiment pas agréables?

Le problème en image :



Pour placer correctement la form au démarrage, pas de problème, mais pour l'empêcher de glisser à cet endroit de façon propre et sans flash écran, ça ne semble pas si simple.

Merci d'avance,
Claude

[MABROUKI]

bonjour ClaudeBg

Si tu maximize la fen MDI Fille la barre de titre est visible avec la crox de fermeture sur le bandeau du menu...
Si tu deplaces une fen MDI Fille par sa barre de titre et qu'elle se trouve cache par la barre de menu des scrollbars apparaissent dans le MDI parent ce qui permet de la rendre visible.........

bon code....

[ClaudeBg]

Salut
-----

Merci de m'avoir répondu.

Si tu maximize la fen MDI Fille la barre de titre est visible avec la crox de fermeture sur le bandeau du menu...

Toutes les fenêtres potentielles ne sont pas pourvues de cette fonctionnalité, sans compter que pour maximiser il faut accès à la barre de titre. En outre, la position des fenêtres est mémorisée, ce qui veut dire qu'une fois que la fenêtre est là, même en fermant et rouvrant la dite fenêtre, elle revient à cette position litigieuse.

Mais bon, au niveau du placement, c'est simple à résoudre, il suffit de s'abonner à l'évènement MdiChildActivate de la MDI et de redéplacer toute fenêtre déposée sous la barre d'outils.

Si tu deplaces une fen MDI Fille par sa barre de titre et qu'elle se trouve cache par la barre de menu des scrollbars apparaissent dans le MDI parent ce qui permet de la rendre visible.........

Ben, tu penses bien que si c'était mon souci je n'aurais pas posté
Le scrollbar apparaît effectivement, MAIS uniquement si on glisse la fenêtre sous la barre de menu. Ça, ça fonctionne correctement.
Ce qui me pose problème ce n'est pas la barre de menu, c'est la barre d'outils, qui, elle, se comporte comme une fenêtre et donc n'est pas prise en compte dans l'espace disponible de la fenêtre: on peut donc glisser dessous une fenêtre sans que les scrollbars n'apparaissent, d'où ma question pour savoir si on sait redélimiter la zone de travail de la fenêtre en tenant compte de la présence d'un scroolbar.

Tiens, une capture pour montrer une fenêtre cachée sans apparition du scroolbar :



Mais là aussi, la solution théorique est simple: je m'abonne à l'évènement LocationChanged et je force la propriété "Top" à rester supérieure au bord inférieur de la barre d'outils. Mon problème, c'est que lorsque je fais ça, j'ai un horrible "flickage" de l'écran lors du déplacement de la fenêtre (mouvement pas propre).

Ma qestion peut donc être posée autrement: comment empêcher une fenêtre de rester dans un espace limité de la MDI sans perturbations d'affichage durant le mouvement?

Je vais tenter une solution alternative, en vérifiant la position des fenêtre sur libération du bouton de la souris. Pas très élégant, mais en attendant...

A+
Claude

[chrismonoye]

Bonjour,

Je pense que cela dépend de la façon de charger le form enfant.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
        Dim f As New Form2()
        f.TopLevel = False
        f.Location = New Point(50, 50)
        Me.Controls.Add(f)
        f.Show()

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
        Dim child As New Form2
        child.MdiParent = Me
        child.Show()

Chez moi, avec la première, j'ai en gros les défauts que vous décrivez.
Avec la seconde, ça convient, et ce que dit MABROUKI est juste.
Donc à tester...

[ClaudeBg]

Salut
-----

Chez moi, avec la première, j'ai en gros les défauts que vous décrivez.

Avec la seconde, ça convient, et ce que dit MABROUKI est juste.

J'utilise déjà ta seconde méthode depuis le début, et ça provoque les problèmes en question (je rappelle: pas avec la barre de menu mais avec une barre d'outils ajoutée sur plusieurs lignes).

Voici le code d'appel:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
            var f = new FormDimmerBg();
            f.MdiParent = (Form)_host;
            f.Show();

Le cast c'est parce que la MDI est référencée comme interface.

Mais j'ai résolu le problème d'une façon qui ne provoque pas des défauts d'affichage durant le mouvement:

Je surcharge WndProc et j'intercepte le message WM_MOVING. Si je sors de la zone autorisée je modifie le rectangle de ma form avant qu'elle ne soit dessinée.

Ça fonctionne sans problème, me reste juste à ajouter le blocage du pointeur pour éviter qu'il ne s'éloigne de ma fenêtre restant bloquée et le tour est joué.

Merci de m'avoir répondu

A+
Claude

[MABROUKI]

rebonjour

Pour le flicker ils ont prevu :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
this.DoubleBuffered=true;

bon code.....

[ClaudeBg]

Salut
-----

Pour le flicker ils ont prevu :

Ça fonctionne pour les contrôles qui doivent se reconstruire car l'affichage bascule simplement entre deux images déjà construites plutôt que de voir la construction de l'image à l'écran. Le flick dans ce cas-là est provoqué par l'affichage d'un dessin incomplet en cours de réalisation.

Par contre ça ne fonctionne pas en verrouillant la position via l'évènement LocationChanged, parce que la fenêtre est correctement affichée à la position illicite, avant de déclencher l'évènement dans le corps duquel on ramène la fenêtre à la position correcte et donc qu'on la redessine. On a donc deux affichages successifs complets à deux positions différentes, donc flick avec ou sans double-buffer. Il aurait fallu un évènement genre "locationChanging" déclenché avant la modification de la position et non après.

C'est pourquoi il fallait remettre la fenêtre en bonne position avant qu'elle ne soit affichée, d'où l'interception des messages. Avec cette interception, il n'y a pas d'affichage en position illicite et donc pas de flick.

Avec WndProc, plus aucun problème, le souci est juste que je suis contraint d'hériter toutes mes fenêtre filles d'une form dans laquelle j'ai implémenté l'interception en question, car je n'ai trouvé aucun moyen de gérer ce verrouillage de position à partir de la fenêtre mère, je dois gérer pour chaque fenêtre fille. Mais bon, on ne peut pas avoir le beurre et l'argent du beurre.

Je vais profiter de cette interception pour mettre en place une gestion des ancrages magnétiques, histoire de "profiter" de cet ajout de code.




A+
Claude

[ClaudeBg]

Salut
-----

Bon, je retourne une information, au cas où quelqu'un rencontrerait le même problème que moi dans le futur:

Problème: la barre d'outils n'est pas prise en compte dans la partie "active" de la MdiClient de la fenêtre MDI: du coup, les fenêtres peuvent glisser dessous et ne pas être récupérables même avec les ascenseurs

Façon dont j'avais procédé:

- J'ai créé un menu ToolStripMenuItem en me servant du designer. Donc, ToolStripMenuItem est contrôle fils de la fenêtre MDI. Il est positionné avec DocK = Top et pris en charge comme emplacement "réservé"

- J'ai créé un ToolStripPanel dans mon code, pour y placer mes outils de façon dynamique. J'ai positionné ce ToolStripPanel aux coordonnées 0,0, donc juste sous le menu et en utilsant Anchor pour qu'il suive les redimensions de la fenêtre. Il n'est pas considéré comme "partie réservée" comme le menu, et donc ça ne fonctionne plus correctement.

La cause du problème:
Le ToolStripPanel n'est considéré comme partie "réservée" de la fenêtre que si sa propriété Dock est utilisée et non un positionnement par top et left.

Première correction :
Ne pas placer avec top,left et anchor mais utiliser Dock = Top

Problème qui survient alors: la barre d'outils est positionnée au-dessus du menu, quelque soit l'ordre de placement.

Seconde correction:

Il faut retirer le ToolStripMenu des contrôles de la fenêtre et le replacer dans le ToolStripPanel en utilisant la méthode "join".

À partir de ce moment les fenêtres ne peuvent plus glisser sous les outils, car le ToolStripPanel devient partie "réservée" non occupée par la MdiClient, et le menu peut au choix être positionné au-dessus ou en-dessous des outils. Les scrollbars fonctionnent de nouveau correctement.

A+
Claude