Discussion :

[zax-tfh]

Bonjour à tous,

Cela fait un moment que ca me titille mais là je fais le pas !
Attention ! question qui me parait toute bete mais que je n'arrive pas à résoudre :

Lors d'un evenement selectionchanged sur une combobox (entre autres), comment faites vous pour savoir s'il provient d'un binding objet ou d'un clic utilisateur ?

Imaginons le scénario suivant :
une form avec une combobox dessus. Au démarrage on remplit la combo avec nos valeurs, puis, comme l'utilisateur a chargé un fichier (ou autre données SGBDR), on remplit notre formulaire avec les valeurs y compris la valeur du combobox. On va donc dire que le selecteditem (ou selectedvalue, peut importe) va prendre la valeur "N". Cela déclenche un evenement selection changed.
Maintenant imaginons que l'utilisateur change volontairement cette valeur en cliquant sur la combo et en choisissant l'item qu'il veut. Cela déclenche également un selectionchanged.

Comment faire pour savoir dans quel contexte on se situe ?
Je demande cela car je suis dans le scénario suivant : lorsque l'utililsateur change la valeur via une selection a la souris -> j'enregistre la valeur dans mon fichier mais lorsque je charge celui ci, je place la selection et donc il me réenregistre la valeur vu que l'on passe toujours dans le selectionchanged.

J'ai bien essayé de passer par des evenements souris mais sur une combo ca passe mal...

Comment procédez vous pour un meme genre de situation que la mienne ?

Merci d'avance
@ bientot

[tomlev]

Je ne suis pas sûr qu'on puisse différencier les 2 cas...
Ce que tu peux faire, c'est attribuer le handler à l'évènement seulement après avoir chargé les données

[zax-tfh]

oui en effet, mais si tu charges pas seulement à la creation t'es marron
J'avais pensé à autre chose sinon, une propriété loading as boolean mise à false. Lors du chargement on la passe à true au debut et apres le chargement on la remet à false
Dans les event handlers, on teste si la property loading est à false pour pouvoir enregistrer les infos sinon on ne fait rien.

Mais sincerement ma question est encore plus globale car je suis vraiment intrigué par vos méthodes de travail :

Comment gérez vous vos enregistrements de données par rapport à l'interface utilisateur ?

je suppose que beaucoup vont me répondre : "j'ai un bouton enregistrer qui se charge de ça. A ça je leur répondrai : "ok c'est assez simple, mais comment gérez vous alors les problemes de plantage ou autre ? si l'utilisateur se tane à remplir un formulaire assez complexe et que ca plante à la fin (ou coupure de jus ou peut importe) il perd toutes ses infos. Ne faites vous jamais d'enregistrement en live ? si oui, comment gérer la partie UI de la partie data comme expliqué dans mon scenar plus haut ?

[tomlev]

oui en effet, mais si tu charges pas seulement à la creation t'es marron

Où est le problème ? tu peux aussi enlever le handler de l'évènement si besoin...

J'avais pensé à autre chose sinon, une propriété loading as boolean mise à false. Lors du chargement on la passe à true au debut et apres le chargement on la remet à false

Dans les event handlers, on teste si la property loading est à false pour pouvoir enregistrer les infos sinon on ne fait rien.[/QUOTE]
C'est pas mal aussi

mais comment gérez vous alors les problemes de plantage ou autre ? si l'utilisateur se tane à remplir un formulaire assez complexe et que ca plante à la fin (ou coupure de jus ou peut importe) il perd toutes ses infos. Ne faites vous jamais d'enregistrement en live ? si oui, comment gérer la partie UI de la partie data comme expliqué dans mon scenar plus haut ?

Il suffit de faire un programme qui ne plante pas
Non mais sérieusement, tu veux pas enregistrer à chaque fois que l'utilisateur modifie un champ ?
Je connais pas une seule application qui fasse ça...

[zax-tfh]

La notre le fait car nos utilisateurs travaillent dans un envirronement qui le demande (tablet pc sur le terrain, il y a souvent des pannes de batterie ou problemes provenant d'ailleurs que notre appli - prefetch, anti virus ou autres trucs à la c..) donc du coup on minimise la perte de données autant que faire se peut. (et aussi le nombre de clicks... en général, ils n'aiment pas trop l'informatique mais sont obligés d'y passer, donc moins y'a de clicks et plus ils sont contents )
Voila le pourquoi du parce que

Bon et puis c'est un progiciel assez particulier, c'est loin des applis de gestion standard.

plus personnellement j'adhere totalement à l'erradication du bouton Enregistrer