Need tip on parent reference

[Edwin Knoppert]

I have a (parent)class pointing to an items class.
The items class holds a reference to the parent class.
This seems to prevent proper unloading.
The parent class does not get signaled for destruction so i can not destroy the items class.

A chicken-egg situation.
Should i use an object pointer?
I think this is bad..

[Cliff Nichols]

I know I saw this somewhere in the docs or in the forums (but my foggy brain can not think of it) but the general idea

Parent ---> Link --->Child
and
Child ---> Link --->Parent

Can EASILY cause a recurrence and never end. (But its all in what and how its done, and the code to escape)

[John Strasser]

I have a (parent)class pointing to an items class.
The items class holds a reference to the parent class.
This seems to prevent proper unloading.
The parent class does not get signaled for destruction so i can not destroy the items class.

A chicken-egg situation.
Should i use an object pointer?
I think this is bad..

Are you referring to an inheritance issue? If that's the case why would you need a child pointing to the parent?

If you're instead talking about class 1 having a variable of class 2 inside it then your destructor for class 1 may need to explicitly call the destructor for class 2.

That's how it works in C++ anyhoo...(still haven't had the time to play with PB9/5 yet)

john

[Edwin Knoppert]

Two classes...

It's like a tree, a node holding childs.
The child has a parent property.

When the childs object (the parent node) is no longer wanted you can set to nothing what you want, the child will keep it alive.
I don't think there is a workaround, it's the way objects work, to be destroyed until all references are unset.

I made a workaround but somehow i guess there is a 'bright' idea how MS does these things.

In c# for example you can move a child node to another parent.
It *may* reset the parent reference in the child object explicitly.

Note that i am not working on a treeview, just a collection of items.

I also changed my perspective the last days and removed all parent properties.
Programming ala OOP style is daunting, lot's of (unclear) crashes to check out.
The debugger is limitted by not showing all states, objects (set/not set) are not shown.
The program 'just' terminates.

Goal is not to force unloads (somehow), an object will unload itself when all references are removed.

Tip:
Use OutputDebugString() to verify objects are released properly!
In the destructor i put some debug stuff to verify.

[Mark Smit]

Hi Edwin,

I recently came across the same issue. What I did was to add another method to force the child objects to "Disconnect" from the parent object. I would call the "Disconnect" method before kiling off the parent.

Item.Connect(Parent)
Item.Disconnect()

In a recursive object structure this works quite well.

[Edwin Knoppert]

I guess so.
Setting the items class to nothing and 'hope' the destructor kills all the items is not going to work.

[Steven Pringels 3]

Edwin,

Have you tried to use a variable (Dword) which holds the ObjPtr to
the cItems class ? Then by using Poke Dword, VarPtr(myClassInstance), dwObjPtr you can obtain the reference of the parent item. Could that work
for you ?

Steven

[Edwin Knoppert]

i am using this in another code fragment..

I also have a propertylistbox which holds a reference to each item this way.
On delete/destroy it's release() call is executed.
On set it's addref()

Note that you should *never* hold an object pointer without using these calls.
Any object variable must maintain the internal counter, even if you use weird peek/poke stuff.
Otherwise you'll make a programming exception (not following the rules)

[Mark Smit]

Hey,

Just another thought here...

You could also have a flag in the parent object class that signals all Items to forget the parent ref.

Here is a small example assuming "Disconnect" is a property in the Parent object class.

Parent.Disconnect = %TRUE
Parent = nothing

IF Item.Parent.Disconnect THEN
    Item.Parent = nothing
ELSE
    Item.Parent.DoSomething()
END IF

[Steven Pringels 3]

i am using this in another code fragment..

I also have a propertylistbox which holds a reference to each item this way.
On delete/destroy it's release() call is executed.
On set it's addref()

Note that you should *never* hold an object pointer without using these calls.
Any object variable must maintain the internal counter, even if you use weird peek/poke stuff.
Otherwise you'll make a programming exception (not following the rules)

Is this true for PB interfaces / classes ? I don't know. You're right about COM but PB is a bit of a black box, it may do things differently.

[Chris Holbrook]

You're right about COM but PB is a bit of a black box, it may do things differently.

It would be nice (for me!) to know what was default PB behaviour without the overhead of COM and an example would be useful, showing the life cycle of a parent/child object relationship. How does the child get a ptr to its parent? Does the parent have to pass it in via a method/SET PROPERTY (I'm trying to avoid PROPERTYs, they just seem to cloud the issue.). Does the child have to do something other than me.destroy to release the parent?

[José Roca]

Does the child have to do something other than me.destroy to release the parent?

COM classes aren't destroyed calling a Destroy, Delete or Free method. They destroy themselves when all the references to them have been released (set to NOTHING).

If you want to learn how it works, you can start here:

http://msdn.microsoft.com/en-us/library/ms687260(VS.85).aspx

[Steven Pringels 3]

We're talking about COM classes right ?

Wel what about the PB classes. Let's say that I've build an object oriented approach to DDT where one can create a bunch of dialogs. NONE of these
object will then be destroyed unless we are closing the LAST dialog, correct ? Some concept-code is as follows...

Dim iDialog as iDDT

iDialog = Class "cDDT"

iDialog.X = 10 .
...
..
iDialog.Build()

This looks like a major memory-hog to me. But... maybe PB does things differently with their native classes. I don't know.

Steven

[Edwin Knoppert]

Why care, it is a class with an addref and release.
In com terms you *must* make sure addref and release are used.
Since an objref() put in a long will never call addref (and release) you'll need to do that manually.

+ i gave you the tip to do so since it is *the* approach.
In a very rare occasion you only store the object ptr and not call addref for things like parent approach.
The ptr may only be used to derive an new reference from like poking it into a dispatch and call addref.
The ptr in this case may become invalid so you have to know what you are doing + it is bad design anyway.

If it's com or not is besides the point, the only important thing to know is that the compiler will destroy the object when the final release occures.

(And yes, PB classes are com based, at all times, which is fine)

[Steven Pringels 3]

Edwin,

I'm not sure that PB Classes are com based. There is no need for a GUID when you define the (internal) classes. Furthermore, this would also mean that one
could pass the iDispatch of PB Class to a COM component requiring a object instance and that doesn't seem to work.

Like

Dim ClsPB as iPBClass

ClsPB = Class "cPBClass"

...

Object Call MyCOMObject.MethodRequiringObject(ClsPB)

[Edwin Knoppert]

From one subject to another..

For a dispatch object you'll need a dual interface.
With or without guid does not matter.

[José Roca]

We're talking about COM classes right ?

Wel what about the PB classes. Let's say that I've build an object oriented approach to DDT where one can create a bunch of dialogs. NONE of these
object will then be destroyed unless we are closing the LAST dialog, correct ? Some concept-code is as follows...

Dim iDialog as iDDT

iDialog = Class "cDDT"

iDialog.X = 10 .
...
..
iDialog.Build()

This looks like a major memory-hog to me. But... maybe PB does things differently with their native classes. I don't know.

Steven

Wrong. You just have an object variable holding a reference to the class, iDialog, and the class will be destroyed when iDialog is set to NOTHING.