Forme.ShowDialog() ou la Forme.ShowDialog(ce)?
J'ai entendu dire que si je l'appelle la forme.ShowDialog() sans indiquer de la propriétaire, il peut y avoir un cas où je ne vais pas voir la boîte de dialogue formulaire sur l'écran (il sera caché avec d'autres fenêtres). Est-il vrai? J'ai utilisé ShowDialog() sans indiquer le propriétaire des centaines de fois et je n'ai jamais eu de problèmes avec ça.
Pouvez-vous nous expliquer dans quelle situation je pourrais obtenir le problème décrit?
Mise à JOUR:
Bien, j'ai fait de nombreuses expériences, et je ne pouvais pas obtenir de réels problèmes inattendus avec l'aide de ShowDialog() (sans spécifier le propriétaire).
Donc je pense que c'est juste des rumeurs qui ShowDialog() peut conduire à des problèmes.
Si vous n'acceptez pas - donnez-moi un exemple de code veuillez qui conduit à un problème.
- Cela ne semble pas s'appliquer dans les winforms, mais pour la petite histoire, je suis venu ici parce que j'ai eu des problèmes dans WPF. Si je suis passé à une autre application, quand j'ai cliqué à nouveau sur le formulaire parent, l'enfant de dialogue s'est coincé derrière (la poisse que la boîte de dialogue enfant a été configuré pour ne pas afficher dans la barre des tâches). Réglage de la propriétaire de la boîte de dialogue corrigé ce problème.
- Démarrer un fond travailleur et appel ShowDialog. La fenêtre n'apparaît pas dans l'avant de votre application, mais sur le fond (juste pour nous énerver programmeurs cela n'arrive que de temps en temps).
- Barfieldmv, j'ai essayé de faire ce que vous avez suggéré et le formulaire s'affiche sur le dessus, pas sur le fond.
- donnez-moi un exemple de code veuillez qui conduit à un problème de mauvaise approche. Le contrat est MSDN, la mise en œuvre de comportement est l'humeur d'aujourd'hui. Des comportements peuvent être différents sur une autre version de Windows, et peut changer avec la mise à jour Windows, les fonctionnalités de Windows ou d'autres programmes. Une fenêtre modale ne avoir un propriétaire, tout le monde attend de vous que vous spécifiez correcte.
- Comme par exemple:
Form1
avec un bouton qui lance un timer de ~1s. La minuterieTick
événement arrête le chronomètre, et ouvreForm2
avecShowDialog
. EnsembleForm2.ShowInTaskbar=false
de sorte qu'il se comporte comme une fenêtre popup. Démarrer le programme, cliquez sur le bouton, puis sélectionnez un autre programme avant que la minuterie se déclenche. Cliquez sur l'icône de la barre d'apporter votre application au premier plan à nouveau. Sur mon système, j'observe: Les handicapés Form1 obtient le focus d'entrée (au lieu de Form2), et en cliquant sur Form1 ne clignote pas Form2 de la barre de titre. - alors pourquoi le contrat avec la boîte de dialogue nous permet de faire la bonne chose et de ne pas le préciser?
- Je suis n'a pas de conception de la WInforms API, mais de mon expérience: il peut être OK, de temps en temps, ou il semblait être une bonne idée à l'époque.
Vous devez vous connecter pour publier un commentaire.
Un désagrément que j'ai trouvé avec
ShowDialog()
vsShowDialog(this)
.Exécuter le TestApp, montrer la
newform.ShowDialog()
, cliquez sur "afficher le Bureau" sur votre barre des tâches ou la barre de lancement Rapide, cliquez sur le TestApp sur la barre des tâches. Il montre la Mainform. Que vous avez à faire un Alt-Tab pour accéder à votre newform.VS
Exécuter le TestApp, montrer la
newform.ShowDialog(this)
, cliquez sur "afficher le Bureau" sur votre barre des tâches ou la barre de lancement Rapide, cliquez sur le TestApp sur la barre des tâches. Il montre la newform sur le dessus."Fenêtre active" se réfère généralement à la fenêtre de premier plan, mais seulement si elle appartient au thread en cours - voir GetActiveWindow dans MSDN.
(Les informations sont dans le contenu de la communauté, mais le commentaire est juste qu'il n'y a pas de "par thread fenêtre active", autant que je sache).
Ainsi, lorsque l'utilisateur a basculé vers une autre application (ou fils) de la fenêtre, vous retrouver avec des "fenêtre par défaut". Même si .NET un peu de magie ici, la modalité sera brisé: le but de la fenêtre parent n'a pas été désactivée (par exemple, vous pouvez passer à votre fenêtre principale, et de la fermer ou de modifier quelque chose, qui, souvent, les pauses de votre application en raison de la réentrée).
Aussi, si une autre application est active, votre boîte de dialogue n'apparaît pas sur le dessus, mais il sera caché derrière une autre fenêtre.
Comme un problème mineur, la position initiale est généralement inexactes ou trompeuses.
En pratique, cela se produit rarement, cependant: si vous ouvrez la boîte de dialogue en réponse à un menu ou un bouton de la souris, cliquez sur votre fenêtre principale, l'utilisateur ne sera pratiquement jamais à passer à une autre fenêtre.
Cependant, il est techniquement possible, et tout à fait susceptible de se produire si vous ouvrez la boîte de dialogue en réponse à une certaine automatisation, de messages externes etc.
Juste pour mieux comprendre le propriétaire appartenant à la relation:
(c) "Pro .NET 2.0 Windows Forms et des Contrôles Personnalisés" par Matthew MacDonald.
(c) "Windows Forms 2.0 Programmation" par Chris Vend, Michael Weinhardt.
Le sans paramètre ShowDialog() utilise simplement un "défaut" de parent.
Pour ce que ça vaut, la valeur par défaut des parents est ce que la "fenêtre active" est. Lorsque vous vous souciez de ce que les parents, vous devez définir explicitement.
Oui, elle permet de faire la différence dans certains cas. Je n'ai eu aucun problème avec la méthode sans paramètre jusqu'à maintenant, et j'ai été un peu surpris de voir que le formulaire parent n'a pas été le formulaire par défaut. Donc, pour éviter un comportement inattendu, toujours transmettre le réel formulaire parent à la méthode ShowDialog.
Prendre l'exemple suivant:
Dans votre formulaire principal, vous avez une liste, avec étiquette d'édition activé. Lorsqu'une étiquette spécifique est édité, le lancement d'une deuxième fenêtre (à l'aide de
ShowDialog()
dansAfterLabelEdit
). Le nouveau formulaire n'est pas afficher dans la barre des tâches.Si votre utilisateur démarre l'édition de l'étiquette, puis clique sur une autre application, puis de la deuxième formulaire s'affichera, mais au moment de retourner à votre application, l'utilisateur ne sera présenté avec votre formulaire principal, désactivé depuis une boîte de dialogue modale est affichée. Pourtant, l'habitude de clignotant mécanisme (qui apporte la boîte de dialogue modale à la police si vous cliquez sur l'appelant) ne fonctionne pas (sans doute parce que l'AfterEdit appel n'a pas retourné), et votre utilisateur ne sera pas en mesure d'atteindre la deuxième forme, sauf en vélo à travers les fenêtres ouvertes à l'aide de Ctrl+Tab.
Appel
ShowDialog(this)
résout ce problème.J'ai eu ce problème et de le résoudre changer les fenêtres de l'état de la propriété à la normale, parce que c'est peut-être réduite au minimum.
Je viens de trouver un cas où ne précisant pas le propriétaire à l'aide de
this
causé un grave problème.Dès le lancement de mon application, les forces lui-même pour passer en mode plein écran et s'assure aussi qu'il a toujours mise au point, même si l'utilisateur tente de Alt+Tab en sortir, sauf si vous ouvrez une session en tant qu'administrateur ou développeur.
Lorsque j'utilise
ShowDialog()
sur un formulaire personnalisé de la boîte de dialogue s'affiche derrière ma demande pour une raison quelconque, et l'application elle-même ne répond pas parce que la boîte de dialogue est actuellement active. Si j'utiliseShowDialog(this)
puis l'écran s'affiche comme prévu.