rincevent a écrit:

Salut Seki,

je suis pas sûr de bien comprendre, est-ce que ton problème peut s'expliquer ainsi ? :

le user est sur une ligne qui peut être effacée.

Oui, quand il met le focus sur cette ligne (p.ex sur un montant saisissable), comme la ligne (la cellule en fait) est "atteignable" car non protégée, le couple menu / barre d'outil montre qu'on peut supprimer

rincevent a écrit:

Le user veut changer la ligne sur laquelle il est mais il clique à un endroit qui en fait ne fait pas changer la ligne courante (=> selection noire)

Tout à fait ça. Comme l'endroit où il a cliqué n'est pas "atteignable", (protect = 1) on n'a pas d'évènement RowFocusChanged() et le menu ne se met pas à jour pour désactiver la suppression.

rincevent a écrit:

Le user croit avoir changé de ligne, demande l'effacement (de la ligne courante) et du coup efface la ligne sur laquelle il était au début (et qui est tjrs restée la ligne courante)

Presque : en fait le truc sioux c'est que le DeleteRow() (qui est exécuté car le menu est actif) se fait avec un GetRow() surchargé dans l'objet qui va aller chercher la première ligne de la "sélection noire" si elle existe et si on est en "grille", ou sinon le GetRow() traditionnel si il n'y a pas de sélection. Du coup on shoote la ligne qui était "visuellement" sélectionnée (fonctionnement cohérent du point de vue de l'utilisateur, sauf que normalement on ne doit pas supprimer cette ligne)

rincevent a écrit:

si c'est ça je dirai qu'il n'y a pas vraiment de problème au niveau de l'appli, plutôt au niveau utilisateur en fait ^^ (qui croit avoir changé la ligne courante alors qu'il n'en est rien) et du coup à part peut être essayer de ne plus afficher la "selection noire" j'aurai pas grand chose à conseiller.

sinon comme event DW concernant le focus y a itemfocuschanged aussi

C'est compliqué, parce que dans notre objet, même si des cases sont protégées, on peut quand même les sélectionner par exemple pour les copier / coller vers excel. Donc la sélection est à conserver.

Et il n'y a pas de itemFocusChanged() quand on clique sur une cellule qui est protégée, vu qu'elle ne peut pas avoir le focus...

C'est bien un bug applicatif qui rate un rafraîchissement du menu quand il aurait dû.
En fait j'hésitais à jouer avec les button_down / button_up de la souris mais j'ai fini par voir que c'était censé être déjà fait par le code dans un évènement mappé sur pbm_dwnlbuttonup mais buggé car ça utilisait getRow() au lieu du row qui est fourni par l'évènement.

Bref une fois posté sur le forum, je finis par trouver. Un peu comme sur StackOverflow...
Merci d'avoir joué le rôle du nounours, et d'avoir lu jusqu'ici

seki a écrit:

Merci d'avoir joué le rôle du nounours

Pour ceux que cette expression aurait pu interroger (mais il fallait lire jusque là ), l'origine est dans le Brian's Guide to Solving Any Perl Problem, qui regroupe une série d'idées en une "philosophie" de debuggage (et ça marche aussi pour autre chose que du Perl ).

Le paragraphe "Avez-vous parlé au nounours ?" est intéressant.
Vous arrive-t-il de bloquer sur un point de dev, pour finir par en parler à un collègue ? Vous êtes en train de décrire le contexte et de (re)formuler la question quand une nouvelle piste vous vient à l'esprit, quand ce n'est pas directement la solution, et sans que le collègue n'ait besoin de parler.

L'auteur explique qu'avant d'aller distraire les collègues de leurs propres problèmes, on peut aussi placer un nounours en peluche sur le bureau et s'adresser à lui, ça fonctionne aussi bien

Dernière modification par seki (15-05-2013 10:50:02)