Announcement

Collapse
No announcement yet.

Need tip on parent reference

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

  • 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..
    hellobasic

  • #2
    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)
    Engineer's Motto: If it aint broke take it apart and fix it

    "If at 1st you don't succeed... call it version 1.0"

    "Half of Programming is coding"....."The other 90% is DEBUGGING"

    "Document my code????" .... "WHYYY??? do you think they call it CODE? "

    Comment


    • #3
      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
      John,
      --------------------------------
      John Strasser
      Phone: 480 - 273 - 8798

      Comment


      • #4
        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.
        hellobasic

        Comment


        • #5
          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.

          Start as you mean to go on.

          Comment


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

            Comment


            • #7
              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
              So here we are, this is the end.
              But all that dies, is born again.
              - From The Ashes (In This Moment)

              Comment


              • #8
                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)

                hellobasic

                Comment


                • #9
                  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
                  Start as you mean to go on.

                  Comment


                  • #10
                    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.
                    So here we are, this is the end.
                    But all that dies, is born again.
                    - From The Ashes (In This Moment)

                    Comment


                    • #11
                      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?

                      Comment


                      • #12
                        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
                        Forum: http://www.jose.it-berater.org/smfforum/index.php

                        Comment


                        • #13
                          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
                          So here we are, this is the end.
                          But all that dies, is born again.
                          - From The Ashes (In This Moment)

                          Comment


                          • #14
                            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)
                            hellobasic

                            Comment


                            • #15
                              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)
                              So here we are, this is the end.
                              But all that dies, is born again.
                              - From The Ashes (In This Moment)

                              Comment


                              • #16
                                From one subject to another..

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

                                Comment


                                • #17
                                  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.
                                  Forum: http://www.jose.it-berater.org/smfforum/index.php

                                  Comment

                                  Working...
                                  X