Comment empêcher les contrôles visuellement en retard sur le redimensionnement dans TableLayoutPanel?

Question

J'ai une disposition de complexité moyenne basée sur plusieurs TableLayoutPanel imbriqués. Le redimensionnement du formulaire provoque le décalage visuel des contrôles dans les tables imbriquées plus profondes derrière le redimensionnement. Premièrement, cela leur donne l'air de bouger pendant que le formulaire est en train de se redimensionner, mais pire, les bords des contrôles sont visiblement coupés lorsqu'ils sont assez longs pour laisser leurs cellules allouées au tableau.

Y at-il un moyen d'empêcher cela ou est-ce le meilleur TableLayoutPanel peut faire?

Édition: Après avoir expérimenté un tas de programmes, je suis arrivé à la conclusion que le retard sur le redimensionnement est un problème omniprésent. Pour moi, il semble que tout le monde a démissionné que c'est inévitable et acceptable. Bien sûr, si elle est en fait inévitable alors accepter cela est beaucoup plus facile :)

La meilleure façon de voir le retard dans votre programme « bonne interface utilisateur » préféré: redimensionner en maintenant la limite gauche et regarder tout droit Les commandes alignées sautent autour (ou alternativement, bord supérieur & contrôles alignés en bas, comme les barres d'état). C'est cassé tout autour.

Si quelqu'un peut fournir de bonnes raisons pour lesquelles cela est inévitable lors de l'utilisation de contrôles Windows natifs, j'accepterai cette réponse. En outre, si vous trouvez un programme utilisant des contrôles natifs qui ne souffrent pas cela, veuillez le dire, cela pourrait aider ...

Answer 1

Cela ne semble pas être possible du tout, y compris WPF (qui est en fait encore pire - voir this question). Qt peut éviter un tel retard, sauf si Aero est activé. Soupir ...

Answer 2

Le problème avec les contrôles natifs dans Windows est que chaque contrôle est responsable de dessiner lui-même ce qui signifie peindre un bitmap à l'écran. Lorsque chaque contrôle d'un contrôle de conteneur est redimensionné, la région de la fenêtre qu'il occupe est invalidée, de sorte que chaque contrôle dans le conteneur est non seulement repeint, mais le conteneur lui-même doit être repeint. En outre, les événements resize/repaint se produisent tous sur le thread d'interface utilisateur, il s'agit donc d'une opération à thread unique. Les mécanismes de base derrière le dessin de fenêtre natif n'ont pas changé depuis que les fenêtres de 16 bits l'ont introduit.

Il existe de nombreux astuces (hacks) que les gens utilisent pour tenter de contourner le problème, comme le double tampon, le rendu hors écran ou simplement la désactivation du redimensionnement.

Pour voir comment cela devrait être, regardez WPF. MS l'a développé comme un moyen de résoudre ce problème.

Si WPF n'est pas une option et que vous utilisez des formulaires Windows, consultez la documentation associée layout de microsoft. Vous pouvez implémenter votre propre moteur de mise en page plutôt que de vous fier aux offres Microsoft de Microsoft.

Answer 3

Définissez DoubleBuffered = true. Vous pouvez le définir sur les formulaires.