Un de nos utilisateurs a envoyé un journal pour notre application .NET WinForms qui indique que l'événement activé se produit avant le Quelqu'un d'autre a-t-il observé Si oui, pourquoi et y a-t-il un moyen de vous assurer que cela n'arrive pas? charger un événement. Je ne pensais pas que c'était possible et que vous avez codé avec l'hypothèse que charge se produirait toujours avant activé .
activé survenant avant charge ?
3 Réponses :
activé vient avant la charge. Si vous souhaitez écrire du code qui doit être exécuté après la charge, vous pouvez utiliser la méthode montrée.
Veuillez trouver ci-dessous la séquence:
- activé
- charge
- montré
Edit: Veuillez vérifier cette très intéressante
Réponse sur ce qui explique WinForms Charger contre des événements montrés edit: j'ai maintenant créé une valeur par défaut Projet WinForm avec WinForm unique. Maintenant, il me donne la séquence
- charge
- activé
- montré
Je suis confus maintenant.
@Ash: J'ai vu ce lien cendre mais dans ma forme MDI, il me montre une séquence activée, charge, montrée ..
@MAHIN Je pense que vous devriez alors préciser votre réponse que c'est l'ordre que vous voyez sur votre formulaire MDI et ne pas l'énoncer comme un fait non qualifié.
de Ordre de Événements sous Windows Formulaires à MSDN:
Démarrage et arrêt de l'application Événements
La forme et les classes de contrôle exposent un ensemble d'événements liés à l'application Démarrage et arrêt. Quand une fenêtre Formulaires Application commence, le démarrage Les événements de la forme principale sont soulevés dans L'ordre suivant:
system.windows.forms.control.handlecreated
System.Windows.Forms.Control.BindingContextChanged
System.Windows.Forms.Form.load
System.Windows.Forms.Control.Vissiblegked
System.Windows.Forms.Form.Activé
System.Windows.Forms.Form.Shown
Quand une application se ferme, le Les événements d'arrêt de la forme principale sont élevé dans l'ordre suivant:
System.Windows.Forms.Form.Flèvement
System.Windows.Forms.Form.Formclose
système.windows.forms.Form.cosed
System.Windows.Forms.Form.Form clos
système.windows.forms.form.deactivate
Utilisez-vous une boîte à Message dans l'un de vos événements de démarrage? Cela peut entraîner des événements de sorte que les événements se déclenchent en dehors de l'ordre en raison de la manière dont les fenêtres de la boucle de messages Windows formulent la boîte de dialogue.
@Ash: Je l'ai vérifié dans la forme MDI et mon point d'arrêt viendra en séquence activée, charge, affichée ... pourquoi donc?
@Ash: variait avec une application fraîche MDI et une application WinForm simple. La séquence MSDN a raison. Mais dans l'une de mes applications précédentes où j'utilise le formulaire MDI, cela me donne le même problème que Hansaa a dans cette question.
Même s'il va à l'encontre de la documentation de Microsoft, cela peut arriver parfois lorsque vous accédez à la variable publique ou à la fonction du formulaire de chargement de l'extérieur du formulaire. Si nécessaire, vous pouvez définir un drapeau dans l'événement affiché et l'utiliser pour quitter le gestionnaire activé avant que le formulaire ne soit chargé.
@HANSAA: +1. Même dans l'une de mes applications MDI existantes, j'ai trouvé ce comportement. En mode Winform ou MDI, ce n'est pas un problème.
Merci Mahin et Ash de prendre le temps d'enquêter sur ceci. Il semble que vous ne puissiez utiliser aucune hypothèse sur l'ordre de ces deux événements. J'ai réalisé que je pouvais déplacer le code qui était en charge dans une méthode appelée à partir du constructeur de la forme, alors je pense que j'ai résolu mon problème de cette façon. En ce qui concerne l'événement montré: nous avons une version 1.1 de l'application, nous ne pouvons donc pas l'utiliser même depuis son introduction en 2.0.
@HANSA: La commande est évidemment laod, activée, affichée ... mais comme vous avez le problème dans un cas, je reçois aussi le même problème.