PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 23 → Membres privés et DataBinding = Bug ?
Membres privés et DataBinding = Bug ?
Débuté par François C., 11 juil. 2018 11:04 - 4 réponses
Membre enregistré
820 messages
Popularité : +3 (3 votes)
Posté le 11 juillet 2018 - 11:04
Bonjour,

Je suis entrain de tester le databiding sur un objet dont les membres sont privés et accessibles par des propriétés.
Donc je créé une classe test :







Puis je créer mes champs par drag&drop de gcltest sur ma fenetre




Les champs prennent le libellé des membres privés.

Les champs sont liés aux membres privé et windev indique qu'il y a un probleme :





Code initialisation de la fenetre :

gclTest est un CTEST
gclTest.p_sChaine = "Chaine 1"
// Chaine2 uniquement en lecture
gclTest.p_sChaine3 = "Chaine 3"
SourceVersEcran(FEN_test,"gclTest")


Si je fais un go :





Déja la.. le databinding semble fonctionner quand meme alors que les membres sont privés, donc non accessibles..

Si je rempli le champs SAI_sChaine2 et que je clique sur le bouton dont le code est :

EcranVersSource(FEN_test,"gclTest") // mise a jour de l'objet
SourceVersEcran(FEN_test,"gclTest")// on rafraichit l'ecran.. on constate que le champ lié au m_schaine2 ne s'efface pas ??
Info(gclTest.p_sChaine2)






m_sChaine2 qui est privé et dont la propriété est en lecture seule a quand même pu être modifiée ...

Par contre, si je change la liaison de chaque champ, pour les lier aux propriétés, on obtient le comportant attendu.

Bug ??
Membre enregistré
253 messages
Popularité : +1 (1 vote)
Posté le 11 juillet 2018 - 12:16
Bonjour

Les attributs d'accès "publique", "privé", ... sont des conventions de codage.
A l'exécution il n'y a rien pour empêcher d'y accéder (ce qui évite le surcoût de vérifier à chaque accès si on a effectivement le droit).

C'est donc en édition (compilateur, avertissements divers, ...) que le travail est fait.
Membre enregistré
1 637 messages
Posté le 11 juillet 2018 - 13:59
Bonjour,

C'est hyper dangereux comme fonctionnement. Un attribut privé ne doit en aucun cas être accessible depuis un code en dehors de la classe.

C'est la première fois que je vois ça. Essaye de faire ça en c# tu vas vite comprendre…

Perso j'enverrai ça au ST. Pour moi c'est un énorme bug.

--
Cordialement,

Philippe SAINT-BERTIN
Membre enregistré
820 messages
Popularité : +3 (3 votes)
Posté le 11 juillet 2018 - 16:20
@Philippe : C'est que j'ai fait effectivement (Envoi ST) .. pour moi y'a un gros souci. mais je voulais votre avis..
c'est ptete moi qui ai mal fait qq chose ! mais bon l'exemple est tout bête..

@Yann : Et en l’occurrence le compilateur n'y a vu que du feu !
Message modifié, 11 juillet 2018 - 16:20
Posté le 12 juillet 2018 - 12:19
C'est pareil avec les indirections

Et aussi quand tu affectes la valeur d'un membre PUBLIC CONSTANT en le passant en paramètre dans une procédure… et ca je dois dire que ca m'arrange car quand tu duplique un objet manuellement à l'aide d'une méthode Copy() ( oublie <= et sérialise pour dupliquer les objets ) c'est plutôt pratique de pouvoir copier les membres privés par cette entourloupe


Mais en effet l'accès par le binding je trouve cela dangereux, même si j'ai tellement eu de soucis avec le binding sur autre chose que les fichiers à une époque que finalement j'ai abandonné et que j'affecte par code ( ce n'est pas cela qui va plomber le temps de dev d'un projet)

Bon dev

Marc Fastré
www.marc-fastre.be