J'ai rencontré le même problème avec WPF, et il semble que cela ait quelque chose à voir avec la façon dont Word gère les événements depuis les fenêtres enfants. Chaque fois que la liste déroulante (ou probablement tout autre contrôle "contextuel" comme un menu contextuel) est dessinée sur l'une des fenêtres de Word, elle devient un peu gourmande et suppose que vous cliquez sur la fenêtre sous-jacente. Je ne sais pas grand-chose sur la façon dont la messagerie fonctionne dans Windows et je n'ai pas eu le temps de trouver la meilleure façon de résoudre le problème, mais basé sur un post quelque part sur la création de fenêtres sans bordure j'ai essayé modifier les styles de fenêtre du contrôle utilisateur WinForms comme suit (fenêtres constantes de style de http://www.pinvoke.net/default.aspx/Constants/Window%20styles.html):
protected override CreateParams CreateParams
{
get
{
CreateParams p = base.CreateParams;
if (!DesignMode)
{
unchecked
{
p.Style = (int)(WindowStyles.WS_VISIBLE |
WindowStyles.WS_POPUP |
WindowStyles.WS_CLIPSIBLINGS |
WindowStyles.WS_CLIPCHILDREN);
}
}
return p;
}
}
curieusement (ou peut-être pas si curieusement pour les gens qui sont plus familiers avec les messages windows), le menu déroulant ne répond au clavier événements (par exemple, cliquez pour faire apparaître la liste, puis utilisez le clavier pour sélectionner un élément).
Fonctionnellement, il ne semble pas y avoir de problème avec le code ci-dessus ... mais je ne suis pas sûr de ce que les ramifications sont de dire que le contrôle utilisateur est un popup au lieu d'un enfant. Un autre article qui se rapporte à ceci est WPF ComboBox doesn't stay open when used in a Task Pane.