Announcement

Collapse
No announcement yet.

Need tip on parent reference

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • José Roca
    replied
    Originally posted by Steven Pringels 3 View Post
    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...

    Code:
    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.

    Leave a comment:


  • Edwin Knoppert
    replied
    From one subject to another..

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

    Leave a comment:


  • Steven Pringels 3
    replied
    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

    Code:
    Dim ClsPB as iPBClass
    
    ClsPB = Class "cPBClass"
    
    ...
    
    Object Call MyCOMObject.MethodRequiringObject(ClsPB)

    Leave a comment:


  • Edwin Knoppert
    replied
    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)

    Leave a comment:


  • Steven Pringels 3
    replied
    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...

    Code:
    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

    Leave a comment:


  • José Roca
    replied
    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/libr...60(VS.85).aspx

    Leave a comment:


  • Chris Holbrook
    replied
    Originally posted by Steven Pringels 3 View Post
    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?

    Leave a comment:


  • Steven Pringels 3
    replied
    Originally posted by Edwin Knoppert View Post
    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.

    Leave a comment:


  • Mark Smit
    replied
    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.

    Code:
    Parent.Disconnect = %TRUE
    Parent = nothing
    
    IF Item.Parent.Disconnect THEN
        Item.Parent = nothing
    ELSE
        Item.Parent.DoSomething()
    END IF

    Leave a comment:


  • Edwin Knoppert
    replied
    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)

    Leave a comment:


  • Steven Pringels 3
    replied
    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

    Leave a comment:


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

    Leave a comment:


  • Mark Smit
    replied
    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.

    Leave a comment:


  • Edwin Knoppert
    replied
    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.

    Leave a comment:


  • John Strasser
    replied
    Originally posted by Edwin Knoppert View Post
    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

    Leave a comment:


  • Cliff Nichols
    replied
    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)

    Leave a comment:


  • Edwin Knoppert
    started a topic Need tip on parent reference

    Need tip on parent reference

    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..
Working...
X