Il est courant d'avoir la demande suivante de l'utilisateur d'une application en production :

"en même temps que vous affectez le champ X existant, faites aussi ..."

Lorsque l'application a 20 ans d'âge, ou que 6 développeurs ont successivement ajoutés les subtilités de leur savoir-faire, ou que le champ est affecté depuis 5 fenêtres ouvertes en parallèle et 12 procédures locales, ou que la recherche de ses affectations donne 452 résultats, ou tout à la fois … la tâche peut s'avérer hasardeuse, sauf avec la solution suivante :

• sélectionner le champ dans l'explorateur de projet,
• clic droit, "nouvelle propriété",
  
• nommer la propriété valeur (permet de surcharger la propriété valeur du WLangage),
• dans le code d'affectation de la nouvelle propriété, ajouter le traitement qui répond à la demande de l'utilisateur final.

C'est terminé. N'importe quel traitement existant qui affecte le champ, y compris par databinding avec SourceVersEcran, où qu'il soit, quel que soit le développeur précédent qu'il l'ait ajouté, passera maintenant par la propriété. Pas besoin de contrôler toutes les affectations existantes du champ, la propriété se comportera comme un trigger d'une base de données.

Les propriétés ainsi créées viennent compléter les propriétés existantes des champs. Les propriétés sont couramment utilisées dans les classes en POO. Mais souvent méconnues pour les champs puisque introduites à partir de la version 25 :