J'ai une combinaison de combat dans un projet Windows Forms avec un événement attaché à l'événement sélectionné sélectionné. L'événement est déclenché lorsque le code sélectionné est modifié à partir du code et de l'entrée de l'utilisateur. Comment détectez-vous si le sélectionneur sélectionné est modifié en raison de la saisie de l'utilisateur?
4 Réponses :
Votre gestionnaire d'événements n'est appelé qu'après l'entrée de l'utilisateur et non après la modification du code de l'index. Soit gérer ce cas là-bas ou mettre un drapeau booléen, il s'agissait d'une entrée de l'utilisateur afin que une autre partie du code puisse voir que le dernier changement d'index était dû à la saisie de l'utilisateur.
Je suis resté coincé dans des situations avant d'où un changement d'interface utilisateur se propage au modèle, le changement de modèle se propage à l'interface utilisateur et crée un cycle sans fin. Avez-vous affaire à quelque chose comme ça?
Si tel est le cas, une solution est de mettre à jour uniquement l'interface utilisateur du modèle uniquement si elles diffèrent. C'est-à-dire: p> si cela ne vous obtient pas ce que vous voulez, une autre option consiste à supprimer temporairement le gestionnaire d'événements: P> ignoreComboBoxEvents = true;
comboBox.SelectedIndex = newIndex;
ignoreComboBoxEvents = false;
...
public void comboBox_SelectedIndexChanged(object sender, EventArgs e)
{
if (ignoreComboBoxEvents)
return;
...
}
+1 Solution belle et flexible avec l'ignore-drapeau. Bonne solution de contournement si vous avez beaucoup de valeurs mises à jour en même temps
J'aime la deuxième solution de contournement. Semble fonctionner bien et pas besoin de drapeaux!
Pouvez-vous utiliser le SelectchanganCommetd événement à la place?
SelectChangecommouvert est soulevé uniquement lorsque l'utilisateur modifie la sélection de la boîte déroulante
EDIT: L'événement SelectChanganCommetd a une défaillance majeure: si vous utilisez F4 pour déposer la liste, puis passez la souris sur votre sélection et utilisez la touche TAB pour accéder au contrôle suivant, il ne s'agit pas.
Il y a un bug [fermé et supprimé] sur Connect à ce sujet, qui suggère d'utiliser l'événement DropdownFose pour attraper ce boîtier de bord. < / p>
+1 Je ne connais jamais un tel événement, sympa! J'utilise toujours un drapeau pour vérifier s'il est modifié par les utilisateurs ou par programme.
J'ai toujours un problème déterminant si SelectChanganCommetd a été provoqué par une flèche, une barre d'espace ou une souris. Je peux gérer ces événements et utiliser les drapeaux boolean , mais cela semble désordonné.
Semblait être très problématique dans mon cas. Je vais compter sur les drapeaux. Merci néanmoins pour l'info
@Json Il n'y a vraiment pas besoin de me remercier, surtout après tout ce temps. Mais merci.
@Stuartd C'est un plaisir de voir que vous enregistrez toujours de temps en temps: D
Vous pouvez définir un drapeau booléen chaque fois que le code sélectionné est modifié par le code et le gestionnaire peut abandonner (réinitialiser le drapeau) chaque fois que ce drapeau est défini.
Pouvez-vous expliquer pourquoi vous voulez faire cela? Il semble que une violation assez sévère de l'encapsulation de faire une méthode agisse différemment en fonction de ce que l'appelait.
Je veux savoir lorsque l'utilisateur a changé une valeur et non seulement lorsque la valeur est initialement définie.