Salut,

     Par rapport à la documentation de PB pour moi tout fonctionne correctement.

     La fonction isnull   attend le paramètre suivant :  A variable or expression that you want to test to determine whether its value is null
     La fonction isValid attend le paramètre suivant :  An object variable or a variable of type Any—typically a reference to an object that you are testing for validity

    Lorsque tu teste isnull (objet ) il ne teste pas la valeur du pointeur mais son contenu hors le pointeur est null donc null object référence

    Le test a effectuer sur un objet est toujours isValid et non pas isNull

cdt
Yanis

Comme le dit lui même son inventeur le Null c'est vraiment la "billion dollar mistake" (erreur à un milliard de dollars)

Le NULL c'est nul

attention, "non instantié" <>  null

Je sais mais pour un objet Powerbuilder il est instancié ou non instancié, il n'est jamais NULL ou non NULL  ( C'était une précision par rapport à ton commentaire ). Une propriété de l'objet est NULL ou non NULL ( variable d'instance ou shared )  sauf s'il s'agit d'une propriété de type objet powerbuilder exemple une variable d'instance de type window.


Cdt
Yanis

Yanis a écrit:

Je sais mais pour un objet Powerbuilder il est instancié ou non instancié, il n'est jamais NULL ou non NULL  ( C'était une précision par rapport à ton commentaire ). Une propriété de l'objet est NULL ou non NULL ( variable d'instance ou shared )  sauf s'il s'agit d'une propriété de type objet powerbuilder exemple une variable d'instance de type window.

Cdt
Yanis

bah non:

powerobject a, b, c
setnull(b)
c = create n_object
//a n'est pas instantié, n'est pas null et n'est pas valide
//b n'est pas instantié, EST null et n'est pas valide (dans le sens que isvalid retourne autre chose que true)
//c est instantié, n'est pas null et est valide

Yanis a écrit:

Je ne vois pas l'intérêt de faire un setnull sur un objet Powerbuilder et d'ailleurs un setNull sur un objet autoinstancied est interdit.
Pour moi un objet PB c'est create et destroy mais jamais setnull car c'est la mise à NULL du pointeur mais pas de suppression de l'objet.

Attention, PB est un langage avec Create + Destroy mais aussi doté d'un ramasse-miettes (garbage collector), comme le C++.

Setnull() sur un objet permet (lire "peut permettre") de libérer une référence à un objet qui peut avoir été créé ailleurs, et qu'on ne veut plus conserver localement. Si jamais c'était la dernière référence active, l'objet est supprimé automatiquement par le garbage collector, même sans appeler de destroy explicite.

L'autoinstancied ça permet juste de ne pas être obligé de créer explicitement (en gros ça existe dès la ligne qui déclare une variable de ce type).

Exemple avec un objet nv_obj dans lequel je trace seulement un message lors des constructor et destructor : je le crée dans un button::clicked, mais ne le détruis pas explicitement :

nv_obj obj
debug_message(classname()+"::clicked", "avant création")
obj = create nv_obj
debug_message(classname()+"::clicked", "fin de l'event")
return

Et je vois :

debug view a écrit:

[11700] [cb_gc::clicked] avant création
[11700] [nv_obj::constructor] création
[11700] [cb_gc::clicked] fin de l'event
[11700] [nv_obj::destructor] destruction

L'objet est détruit, mais pas par moi. La mise à null du pointeur vers l'objet (la variable de son type) déclenche la destruction de l'objet (si c'était la dernière).

Salut,

      Merci Powerdestroyer. tu as très bien résumé ce que j'essayé de dire, sauf que moi j'utilise toujours le DESTROY.

Cdt
Yanis

PowerDestroyer a écrit:

Le DESTROY, lui, est très utile car même si PowerBuilder est sensé détruire tout seul les objets inutilisés, il ne le fait pas toujours bien, et de façon peu prévisible, notamment quand il y a des références croisées.
Ex : Objet1 a une variable d'instance Objet2, Objet2 a une variable d'instance Objet1.
A moins de faire les destroy ou de déclencher manuellement le GarbageCollect(), il y a de fortes chances que les objets ne soient jamais détruit.

Je viens de tester et je confirme :
- si on crée 2 objets qui peuvent avoir en variable d'instance une référence vers un autre objet et qu'on affecte o1->o2 et o2->o1 les objets ne sont collectés quand ils quittent le scope (= quand on sort du bloc qui contenait la seule référence vers ces objets)
- et même simplement si on affecte o->o (référence cyclique directe), l'objet n'est pas détruit en quittant le scope

Le log montre que tous ces objets qui traînaient encore en mémoire (références croisées, et self-référence) ne sont nettoyés qu'à la fermeture de l'application.