Il existe quelques notifications basées sur ce qui se passe.
Si vous sélectionnez un élément et que rien n'est encore sélectionné, vous recevrez une notification de modification LVIF_STATE: uNewState & LVIS_SELECTED. Le nouvel élément sélectionné à l'adresse:
pNMListView->iItem
Si un élément est sélectionné avant de sélectionner un nouvel objet, vous aurez trois changements d'état:
D'abord, vous serez informé que l'élément précédent mise au point est en train de perdre l'accent:
pNMListView->uOldState & LVIS_FOCUSED
Ensuite, vous serez informé que l'ancien élément est désélectionné:
pNMListView->uOldState & LVIS_SELECTED
Enfin, vous obtiendrez le nouvel état de sélection d'article:
pNMListView->uNewState & LVIS_SELECTED
(regarder à nouveau iItem pour les nouveaux élément sélectionné)
donc le piège que nous avons couru est à travers, parce que les résultats point de désélection dans deux notifications , nous faisions beaucoup de traitement répétitif, parfois préjudiciable. Ce que nous avons fini par faire était seulement de faire ce traitement pour le 2ème message (pNMListView->uOldState & LVIS_SELECTED)
, et de sauter le même traitement après la notification de perte de focus.
Ce ne sera pas attraper un changement quand vous sélectionnez trois éléments avec décalage, mais sélectionnez-en un (ce qui désélectionne les deux autres, mais garde celui-ci sélectionné). Une solution de contournement pour cela, sauf conserver une liste d'éléments sélectionnés? –
Je ne peux pas le tester maintenant mais je pense que vous aurez besoin d'attraper la désélection ainsi que la sélection: pour attraper la désélection, utilisez 'if ((pNMListView-> uChanged & LVIF_STATE) && (pNMListView-> uOldState & LVNI_SELECTED) &&! (PNMListView -> uNewState & LVNI_SELECTED)) ' – djeidot
@djeidot: Merci beaucoup, ça m'a aidé. Lorsqu'il est intégré dans sa propre classe de contrôle, cela peut aussi être réduit à ON_NOTIFY_REFLECT (LVN_ITEMCHANGED, & OnItemSelected) – mox