Les expressions de PowerBuilder sur la colonne contrôlent le comportement étrange

Question

Je travaille sur une application PowerBuilder héritée, nous avons mis à niveau vers PowerBuilder 12 mais continuons à utiliser l'IDE "classique".

Je dispose d'un DataWindow de partage de données avec une DataWindow libre, les deux ancêtres héritiers assurant que lorsque la ligne courante change dans la grille, la forme libre défile sur la même ligne.

J'ai commencé à utiliser des expressions sur les propriétés Protect et Background.Color des contrôles de colonne dans le formulaire libre pour simuler l'activation/la désactivation, comme alternative à l'utilisation de DataWindow.Modify sur rowfocuschanged. Jusqu'ici j'ai apprécié cette approche, il semble beaucoup plus propre, et il n'y a aucune pénalité de performance apparente puisque je n'accède à la base de données dans aucune de mes expressions. Le problème est que, pour des raisons que j'ai du mal à épingler, ces expressions provoquent parfois l'échec de la fonctionnalité de synchronisation de lignes mentionnée ci-dessus.

Dans mon scénario de test, il y a deux lignes dans la grille. La sélection de la ligne 2 ne fait pas défiler la forme libre vers la ligne 2, malgré le fait que le débogage révèle que ScrollToRow est en effet appelé normalement. Ensuite, je sélectionne à nouveau la ligne 1, je ne sais pas si cela fonctionne ou non puisque la forme libre n'a jamais quitté la ligne 1 pour commencer. Ensuite, je sélectionne la ligne 2 une seconde fois, et la forme libre défile vers la ligne 2 correctement, et dorénavant les choses sont dandy.

J'ai résolu ce problème une fois déjà sur une fenêtre différente en déplaçant le code autour d'une expression particulière, aucune idée pourquoi cela a fonctionné, les changements n'ont pas affecté le résultat de l'expression. Malheureusement, je n'ai pas de temps si facile à fixer sur ma fenêtre actuelle. Jusqu'à présent, je peux résoudre le problème en cas de perte de fonctionnalité en supprimant l'expression Protect d'une colonne DateTime EditMask donnée ou en définissant TabOrder d'une colonne DateTime EditMask précédente sur une valeur positive. La première colonne nécessite l'expression Protect et la deuxième colonne doit être non modifiable. J'ai tenté de donner à la deuxième colonne un TabOrder positif tout en mettant son expression Protect à 1 mais cela n'a pas fonctionné. Je me suis arraché les cheveux et je déteste PowerBuilder quelque chose de féroce! J'apprécierais que quelqu'un ait une idée du problème et de la façon dont je peux continuer à tirer parti des expressions de colonne tout en l'évitant. Je répugne à revenir à la manipulation de ce genre de choses via Modifier depuis rowfocuschanged.

Answer 1

Voici la réponse rétrospectivement, en prenant et en ajoutant à ce qui a été développé dans les commentaires.

Lorsque vous définissez une nouvelle ligne, PowerBuilder tente de définir la colonne sur la même colonne que celle actuellement sélectionnée dans la ligne en cours. Cela fonctionne bien dans le cas de base, mais lorsque l'attribut Protect a une expression, les choses peuvent être un peu moins prévisibles. Je ne suis pas sûr qu'il existe un comportement documenté ou prévu dans le cas où la colonne dans la ligne de destination est protégée, mais ma position de sécurité est que le comportement est imprévisible, et vous ne devriez probablement pas le faire. Comme Mike l'a prouvé, la définition explicite de la colonne résout son problème.

L'autre élément important à vérifier si vous tentez de résoudre un problème similaire est de vous assurer que RowFocusChanging ne renvoie pas 1 pour empêcher le changement de ligne.

Bonne chance,

Terry.

Answer 2

J'ai rencontré un problème similaire dans lequel non seulement les champs sont protégés, mais aussi les couleurs d'arrière-plan et de texte sont modifiées lorsque le focus de ligne change.

Pour une raison quelconque, les expressions de Datawindow sont assez incohérentes, en particulier lorsqu'il existe d'autres styles tels que des cases à cocher. Supprimer toutes ces expressions de l'objet datawindow et les placer toutes dans un événement/fonction utilisateur dans le contrôle datawindow qui est appelé depuis l'événement rowfocuschanged() de la liste de grille à l'aide de Post() semble faire l'affaire. De plus, cela vous donnera plus de contrôle sur le moment où les événements se déclenchent réellement, au lieu d'avoir du code sur les expressions dw.