PowerBuilder à Donf ! / [RESOLU] Changement de ligne et validation

elfeliz · 29-07-2011 10:02:19

Bonjour à toutes et tous !

J'ai un bête problème et je ne m'en sors pas ...

Dans une dw, un champs editable sert d'argument à des recherches pour remplir d'autres champs en automatique.
Typiquement, un numéro de client me sert à ramener l'adresse en auto dans le champs voisin, suite à un query sql sur la db.

Jusque là c'est assez simple...

Pour ce faire, on a du code d'ans l'itemchanged qui permet d'aller chercher les infos en db en fonction du nom encodé et du type de client ( récupéré d'une dddw).
Quand on presse tab ou enter, le focus va aux champs à remplir suivant, le champs adresse étant rempli en auto au passage.
Si le numéro de client est erroné (pas d'adresse retrouvée en db), on a un message d'erreur levé par un return code dans l'itemchanged, et le focus revient sur la donnée erronée.
Cela marche pas trop mal.

Par contre, si on rentre un mauvais numéro et qu'on clique sur une autre ligne, j'ai bien un message d'erreur me prévenant qu'il y a un problème, mais le changement de ligne se fait quand même !!!

Quelle action entreprendre pour bloquer le changement de ligne ?
NB : Accepttext, placé au niveaux rowfocuschanged/ing ne lève pas d'erreur (pas de validation rules sur le champ...)...

Merci pour toute piste !

Bybye,
Elfeliz

Dernière modification par elfeliz (30-07-2011 14:16:50)

xlat · 29-07-2011 10:38:29

Pour empêcher le changement de ligne il faut faire un "return 1" dans le rowfocuschanging.
Maintenant si l'accepttext() ne lève pas d’erreur, c'est probablement que la datawindow n'en voit pas : il faut que tu vérifies en plus de l'accepttext() que le numéro de client est valide au niveau rowfocuschanging, ou alors que le code du client soit rejeté dans l'itemchanged (return 1).

elfeliz · 29-07-2011 13:45:11

Oui, je crois que je vois ça comme ça aussi... mais je dois sans doute me planter sur une bêtise

Pour éviter de coder dans rowfocuschanging la logique déjà présente dans itemchanged, je croyais qu'un accepttext placé là - même s'il ne voit pas d'erreur de validation - relancerait systématiquement l'itemchanged et que le contrôle aurait lieu.
Il y a dans l'itemchanged un return 1 : c'est lui qui fonctionne nickel si on presse sur tab/enter... c'est lui aussi qui me lève le message d'erreur, je pense...

Sans doute que je me trompe dans l'ordre de séquence des events : c'est l'itemcanged qui appele l'acceptext et pas le contraire ???!

erasorz · 29-07-2011 14:20:24

D'après la doc :

AcceptText can trigger an ItemChanged or an ItemError event.

AcceptText in the ItemChanged event Calling AcceptText in the ItemChanged event has no effect.

elfeliz · 29-07-2011 15:06:01

Bon ok, je me remets doucement sur les rails...

La séquence est :
j'encode quelquechose de neuf et je fais un tab -> accepttext -> itemchanged -> itemerror

Dans l'itemchanged j'ai le code de validation, et si c'est ko, je passe une variable 'canchangerow' à false.

Maintenant quand je passe dans le rowfocuschanging, je contrôle cette variable.
Si false -> je fais un return -1 et l'affaire est faite : l'utilisateur reçoit son message et reste sur la ligne et la cellule erronée.

Pour compléter le tout, il faudrait que je puisse obliger le user à changer la valeur qu'il a encodée, sans quoi au deuxième tab/row change, il passe... puisque pas de changement et itemchanged non provoqué...

Travaillant depuis longtemps "sous framework", où tous ces events étaient gérés, j'ai bien du mal à m'y remettre...
c'est normal, docteur ?

Merci en tous cas pour vos "remises en jambes" !

elfeliz · 29-07-2011 16:30:15

Pom pom pom pom...

il suffit d'initialiser correctement la variable et de faire les changements au bon moment...

canChangeRow = true à l'ouverture de fenêtre
canChangeRow = true à l'entrée du itemchanged
canChangeRow = false si problème dans itemchanged

et c'est une affaire qui roule...

Merci de votre patience