Apparemment, System.Windows.Forms.RichTextBox.ScrollToCaret peut provoquer le traitement d'événements supplémentaires dans son appel. Lorsqu'il est placé dans un gestionnaire d'événements, il peut faire apparaître le code dans un mode multievent (pas vraiment multithread mais tout aussi déroutant) provoquant des conditions de course. Excusant à l'avance pour les détails manquants:TextBox ScrollToCaret provoquant une confusion de threads
1) application Windows Form .NET 3.5 C#
2) Créer une toile et RichTextBox
3) Démarrer un thread de travail qui appelle canvas.Invalidate() à 30fps .
4) Capturez OnMouseMove() et Paint() pour le canevas.
5) Dans OnMouseMove, ajoutez du texte à un RichTextBox et appelez ScrollToCaret().
6) Utilisez une courte distance statique _eventdepth ++ en haut et - en bas de OnMouseMove et OnPaint.
7) Piège lorsque la valeur de _eventdepth> 1. Trace de la pile:
Canvas::OnPaint()
[External Code]
Canvas::OnMouseMove(), scrollToCaret() is within
Est-ce comportement documenté et censé travailler comme ça - sont il y a « GUI » appels qui distribueront « enfant » événements? Partage cela au cas où quelqu'un d'autre commence à brûler du temps ou au cas où je suis mal compris ce qui se passe.
--- --- modifier
J'ai aussi maintenant enveloppé l'appel à canvas.Invalidate (étape 3) du fil secondaire avec BeginInvoke. J'ai également eu un verrou qui bloquait quand cela arrive Windows commence à distribuer des événements supplémentaires (dans le même thread primaire) comme une solution plutôt que de bloquer (et se bloquer comme je l'aurais prévu). Le ScrollToCaret() continue d'appeler OnPaint() depuis la même pile. Est-il évident pour les programmeurs Windows quelles méthodes peuvent déclencher des distributions d'événements supplémentaires?