dcsimg


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 5 FirstFirst 12345 LastLast
Results 31 to 45 of 65

Thread: Set MyObject=Nothing?

  1. #31
    Michael Culley Guest

    Re: Set MyObject=Nothing?


    David,

    >I don't think setting object references to nothing in the terminate event
    >would help here. When the Stop button is pressed or when Stop or End is
    >in encountered in code the application ends immediately without any terminate
    >events firing.


    If you have a COMPILED usercontrol on a form which is running in the IDE
    and someone pushes stop, the Usercontrol_Terminate event will fire.

    Michael Culley



    "David Hay" <david.hay@aspect.com.au> wrote:
    >
    >"Michael Culley" <m_culley@one.net.au> wrote:
    >
    >>>Why? When the module goes out of scope, or the app ends, the references
    >>>will be released.

    >>
    >>I found odd behaviour here once in a usercontrol when someone using the

    >compiled
    >>usercontrol in an exe pushed the stop button. I can't remember all the

    details
    >>(weak circular reference were invlolved) but once bitten...
    >>

    >
    >I don't think setting object references to nothing in the terminate event
    >would help here. When the Stop button is pressed or when Stop or End is
    >in encountered in code the application ends immediately without any terminate
    >events firing.
    >>>Yes, it does. I do not argue that.

    >>
    >>In one case I know of VB does not do the default behavoiur if you do it

    >for
    >>it. eg:
    >>
    >>Sub ABC
    >> Dim x as long
    >> Dim y as long
    >> x=1
    >> y=x
    >>end sub
    >>
    >>In this case vb does not initialise x or y to zero because you initialise
    >>them youself. I thought it may be the same for Set obj=Nothing but VB does
    >>do it twice.
    >>
    >>>One early DAO version,
    >>>for example, did not properly release resources if you did not explicitly
    >>>close recordsets and/or databases.)

    >>
    >>I would never leave a recordset open at the end of function. We had someone
    >>at work who routinely did this. One day he forgot to put in rs.update.

    I
    >>think ado will update when you do a movenext anyway, but the last record
    >>was not being saved because it never got an update. If there had been a

    >.close
    >>there he would have got an error to alert him to the problem.
    >>
    >>One question. Do you do the set obj=Nothing in your error handling code

    >also?
    >>
    >>Michael Culley
    >>
    >>
    >>
    >>"Bob Butler" <butlerbob@earthlink.net> wrote:
    >>>"Michael Culley" <m_culley@one.net.au> wrote in message
    >>>news:39f2d315$1@news.devx.com...
    >>>> A better example would be do you set variables to default values at

    the
    >>>start
    >>>> of functions?
    >>>
    >>>That's still not a good example but in most cases if I depend on a specific
    >>>value being there I do set it, even if it is the default. I've been burned
    >>>more than once in various languages when default behavior changed and

    I've
    >>>learned not to rely on it when I can easily avoid it.
    >>>
    >>>> I had a poke around to see what VB does and it seams that it still does
    >>>the
    >>>> Set Obj=Nothing itself even if you do it.
    >>>
    >>>Yes, it does. I do not argue that. What I do believe is that having

    the
    >>>code do it explicitly shows me exactly when and where in my code I no

    longer
    >>>need it. It also serves to remind me to call any .Close or other method
    >>>needed to shut down cleanly. I see a lot of code where people rely on

    >the
    >>>variable going out of scope and then rely on the termination doing
    >>>cleanup... I've always held that better to take complete control over

    >the
    >>>lifetime of any objects you use and the upcoming changes in VB.Net are

    >going
    >>>to force people to do just that in a lot more cases.
    >>>
    >>>The current versions of VB handle it for you and do it properly (at least

    >>in
    >>>most cases - I do not know offhand of any objects that do not shut down
    >>>cleanly now although I have seen them in the past. One early DAO version,
    >>>for example, did not properly release resources if you did not explicitly
    >>>close recordsets and/or databases.) If you are comfortable in relying

    >on
    >>>the VB cleanup now then by all means do so. I always try to code with

    >an
    >>>eye towards moving to new versions and/or other languages down the line

    >>so I
    >>>prefer to be as explicit as possible. For me it has paid off in the past
    >>>and it looks like it's going to make VB.Net easier to adopt.
    >>>
    >>>> There is one case where I use it and that is in terminate events for
    >>>object
    >>>> dimmed at the module level.
    >>>
    >>>Why? When the module goes out of scope, or the app ends, the references
    >>>will be released. You don't trust VB to do that correctly somehow? As

    >>long
    >>>as you do not have circular references set up it will all be handled
    >>>automatically...
    >>>
    >>>As far as I'm concerned, always releasing references lets you control

    the
    >>>order and timing and makes the code more self-documenting.
    >>>
    >>>

    >>

    >



  2. #32
    mrfelis Guest

    Re: Set MyObject=Nothing?

    Anthony Jones <yadayadayada@msn.com> wrote in message
    news:39f33e51$1@news.devx.com...
    > Bob,
    >
    > I agree. I am unconvinced. :-)
    >
    > Can you give an example of when the order in which objects are released is
    > important?


    DAO Recordset/Database objects? Who wants to rely on MS to do it right?
    --
    ~~~
    C'Ya,
    mrfelis
    mrfelis@yahoo.NOSPAM.com
    just remove the spam




  3. #33
    mrfelis Guest

    Re: Set MyObject=Nothing?

    John, I never bothered to analyse Form2's code cause I don't need to, an
    incomplete analysis isn't an incorrect analysis.


    --
    ~~~
    C'Ya,
    mrfelis
    mrfelis@yahoo.NOSPAM.com
    just remove the spam
    John Perkins <perk_j@yahoo.com> wrote in message
    news:39f20c4d$1@news.devx.com...
    >
    > mrfelis,
    >
    > Also, your analysis of my code is incorrect anyway because you neglected
    > to notice that I was unloading form2 in when you click Form2.Command1.
    >
    > Private Sub Command1_Click()
    >
    > Unload Me
    >
    > End Sub
    >
    >
    > -John Perkins
    >
    > "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    > >This is not a good example John. VB adds variables Form1 and Form2 to

    the
    > >project's symbol table (or whatever VB calls the symbol table). This can

    > be
    > >visualized by thinking of an BAS module in the project which contains the
    > >following declarations:
    > >
    > >Public Form1 As New Form1
    > >Public Form2 As New Form2
    > >
    > >As you add/remove/rename the forms through the IDE, VB will alter these
    > >entries in the symbol table. So if you change Form2's name to frmTest, VB
    > >will change the declaration to:
    > >
    > >Public Form1 As New Form1
    > >Public frmTest As New frmTest
    > >
    > >Knowing this let's look at the code again (assuming the first click):
    > >>
    > >> Option Explicit
    > >>
    > >> Private Sub Command1_Click()

    > >
    > >At this point Form2 is nothing. The only way to see this is to put a
    > >breakpoint on or before the next line and inspect Form2.
    > >
    > >> Form2.Init

    > >VB creates a Form2 object, assigns the object to the global object

    variable,
    > >Form2, that VB created for you. The ref count for the object is increased

    > by
    > >1. Finally, VB calls the Init method of this object. The form is

    initialized
    > >soemwhere in this mess of code VB adds for you.
    > >
    > >> Form2.Show

    > >Had Init not caused the Form2 object to load, VB would load the form for

    > you
    > >now as well as showing it. Once the form loads VB adds the form to the

    Forms
    > >Collection. This increases the ref count of the object by 1 again. So the
    > >Form2 object's ref count is at least 2 at this point.
    > >
    > >> ' When the form is not set to nothing, it doesn't really
    > >> ' go away. Try un-commenting this line and see the results.
    > >> ' Set Form2 = Nothing

    > >
    > >In doing this, you release 1 reference to Form2 objects Ref Count by 1.
    > >Since the Forms collection has a reference to this Form2 object the

    object
    > >remains instantiated. The only way to get the Form2 object out of the

    Forms
    > >collection is to Unload it.
    > >
    > >> End Sub
    > >>

    > >
    > >VB isn't really acting differently. MS just did some things behind the
    > >scenes that (while violating good programming practice) make it easier to
    > >get started doing things.
    > >
    > >--
    > >~~~
    > >C'Ya,
    > >mrfelis
    > >mrfelis@yahoo.NOSPAM.com
    > >just remove the spam
    > >
    > >

    >




  4. #34
    mrfelis Guest

    Re: Set MyObject=Nothing?

    > It is a good example as it illustrates exactly what I am talking about.
    You said "...forms that are called implicitly without
    an object variable, where VB behaves differently..."

    Except the example doesn't do illustrate VB behaving differently. What the
    example does is show a form and then set the global form variable to
    nothing. Then it shows another form2. This is an illustration of the Dim ...
    As New ... declaration structure. If you don't believe me try this one. Put
    this code in Form1 as click command 1 several times. The only difference
    between my code and your code is that I'm using a local variable that
    automatically looses the reference the the newly created object and you are
    using a global variable and throwing away the reference to the newly created
    object explicitly.

    Private Sub Command1_Click()
    dim fAsNew as new form2


    fAsNew.Init
    fAsNew.Show

    ' Don't need to Set fAsNew = Nothing since VB will do it for you.
    End Sub



    >You
    > obviously didn't run the code twice and see the difference when you hit

    Command1
    Nope, I didn't. I already know what happens for the second run (and any
    thereafter). When you reference the Form2 variable on the second run, VB
    looks at Form2, sees that it Is Nothing, and (following the As New
    declaration) creates a brand new Form2 object.

    > the second time after you've clicked Command1 on Form2 in each case. In

    the
    > case where you don't set the object to nothing, VB "keeps" the implicit

    form
    > object variable for you somewhere in memory; part of VB's optimization.

    That somwewhere in memory is "Form2". Form2 is the only implicit form object
    variable for Form2 in the entire project. So when you when you don't set it
    to nothing the Form2 variable continues to point to the copy of Form2 that
    you loaded the first time.

    Don't let the overriding of the form's class definition name (this is the
    name that you enter into the property dialog) and implicit object variable
    name confuse you. When you use form2 in code 99% of the time your are using
    the object variable. (You only used the variable in your sample.) The class
    definition name is used:
    1. at the end of a Dim statement
    2. at the end of a set object = New statement
    3. at the end of the Typeof object Is expression.

    This isn't likely to be a complete list, but hopefully it will help you
    recognise the difference.

    This whole process could be done for any creatable class using the following
    code:
    'In form1's declaration
    Private moObjects as collection
    'In form1's load
    Private Sub Form_Load()
    Set moObjects = new collection
    End Sub

    Private Sub Command1_Click()
    dim oAsNew as new clsAnyClass
    'Use whatever class name you are allowed to create in your project that
    you want

    oAsNew.SomeMethod

    'Add the object to a collection to similate the forms collection
    moObjects.Add oAsNew

    ' Don't need to Set oAsNew = Nothing since VB will do it for you.
    End Sub


    --
    ~~~
    C'Ya,
    mrfelis
    mrfelis@yahoo.NOSPAM.com
    just remove the spam
    John Perkins <perk_j@yahoo.com> wrote in message
    news:39f20b06$2@news.devx.com...
    >
    > mrfelis,
    >
    >
    > Try the code again. First comment out the set = nothing line. Click

    Command1
    > on Form1. Look at the results in Form2. Click Form2.Command1 to "Unload"
    > the form. Click Form1.Command1 again.
    >
    > Now do the same with the Set Form2 = Nothing line not commented out.
    >
    > -John Perkins
    >
    >
    > "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    > >This is not a good example John. VB adds variables Form1 and Form2 to

    the
    > >project's symbol table (or whatever VB calls the symbol table). This can

    > be
    > >visualized by thinking of an BAS module in the project which contains the
    > >following declarations:
    > >
    > >Public Form1 As New Form1
    > >Public Form2 As New Form2
    > >
    > >As you add/remove/rename the forms through the IDE, VB will alter these
    > >entries in the symbol table. So if you change Form2's name to frmTest, VB
    > >will change the declaration to:
    > >
    > >Public Form1 As New Form1
    > >Public frmTest As New frmTest
    > >
    > >Knowing this let's look at the code again (assuming the first click):
    > >>
    > >> Option Explicit
    > >>
    > >> Private Sub Command1_Click()

    > >
    > >At this point Form2 is nothing. The only way to see this is to put a
    > >breakpoint on or before the next line and inspect Form2.
    > >
    > >> Form2.Init

    > >VB creates a Form2 object, assigns the object to the global object

    variable,
    > >Form2, that VB created for you. The ref count for the object is increased

    > by
    > >1. Finally, VB calls the Init method of this object. The form is

    initialized
    > >soemwhere in this mess of code VB adds for you.
    > >
    > >> Form2.Show

    > >Had Init not caused the Form2 object to load, VB would load the form for

    > you
    > >now as well as showing it. Once the form loads VB adds the form to the

    Forms
    > >Collection. This increases the ref count of the object by 1 again. So the
    > >Form2 object's ref count is at least 2 at this point.
    > >
    > >> ' When the form is not set to nothing, it doesn't really
    > >> ' go away. Try un-commenting this line and see the results.
    > >> ' Set Form2 = Nothing

    > >
    > >In doing this, you release 1 reference to Form2 objects Ref Count by 1.
    > >Since the Forms collection has a reference to this Form2 object the

    object
    > >remains instantiated. The only way to get the Form2 object out of the

    Forms
    > >collection is to Unload it.
    > >
    > >> End Sub
    > >>

    > >
    > >VB isn't really acting differently. MS just did some things behind the
    > >scenes that (while violating good programming practice) make it easier to
    > >get started doing things.
    > >
    > >--
    > >~~~
    > >C'Ya,
    > >mrfelis
    > >mrfelis@yahoo.NOSPAM.com
    > >just remove the spam
    > >
    > >

    >




  5. #35
    John Perkins Guest

    Re: Set MyObject=Nothing?


    It is obvious to me from your posts that you really haven't followed this
    thread and still don't understand what the original intent of my example
    was. If you did, you wouldn't be making the arguments you are making. And
    you certainly wouldn't be talking to me like I don't understand what is going
    on; I most certainly do.

    This is what my example was showing... That in some cases (like when you
    rely on VB to handle the object variable for a form FOR YOU, if you don't
    set the object variable to nothing, it does not go away at the end of a procedure.
    The whole reason I brought this up was as a possible explanation of why some
    people (not me) think that you should always set object varibles to nothing.

    -John


    "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    >> It is a good example as it illustrates exactly what I am talking about.

    >You said "...forms that are called implicitly without
    >an object variable, where VB behaves differently..."
    >
    >Except the example doesn't do illustrate VB behaving differently. What the
    >example does is show a form and then set the global form variable to
    >nothing. Then it shows another form2. This is an illustration of the Dim

    ...
    >As New ... declaration structure. If you don't believe me try this one.

    Put
    >this code in Form1 as click command 1 several times. The only difference
    >between my code and your code is that I'm using a local variable that
    >automatically looses the reference the the newly created object and you

    are
    >using a global variable and throwing away the reference to the newly created
    >object explicitly.
    >
    >Private Sub Command1_Click()
    > dim fAsNew as new form2
    >
    >
    > fAsNew.Init
    > fAsNew.Show
    >
    > ' Don't need to Set fAsNew = Nothing since VB will do it for you.
    >End Sub
    >
    >
    >
    >>You
    >> obviously didn't run the code twice and see the difference when you hit

    >Command1
    >Nope, I didn't. I already know what happens for the second run (and any
    >thereafter). When you reference the Form2 variable on the second run, VB
    >looks at Form2, sees that it Is Nothing, and (following the As New
    >declaration) creates a brand new Form2 object.
    >
    >> the second time after you've clicked Command1 on Form2 in each case. In

    >the
    >> case where you don't set the object to nothing, VB "keeps" the implicit

    >form
    >> object variable for you somewhere in memory; part of VB's optimization.

    >That somwewhere in memory is "Form2". Form2 is the only implicit form object
    >variable for Form2 in the entire project. So when you when you don't set

    it
    >to nothing the Form2 variable continues to point to the copy of Form2 that
    >you loaded the first time.
    >
    >Don't let the overriding of the form's class definition name (this is the
    >name that you enter into the property dialog) and implicit object variable
    >name confuse you. When you use form2 in code 99% of the time your are using
    >the object variable. (You only used the variable in your sample.) The class
    >definition name is used:
    > 1. at the end of a Dim statement
    > 2. at the end of a set object = New statement
    > 3. at the end of the Typeof object Is expression.
    >
    >This isn't likely to be a complete list, but hopefully it will help you
    >recognise the difference.
    >
    >This whole process could be done for any creatable class using the following
    >code:
    >'In form1's declaration
    >Private moObjects as collection
    >'In form1's load
    >Private Sub Form_Load()
    > Set moObjects = new collection
    >End Sub
    >
    >Private Sub Command1_Click()
    > dim oAsNew as new clsAnyClass
    > 'Use whatever class name you are allowed to create in your project that
    >you want
    >
    > oAsNew.SomeMethod
    >
    > 'Add the object to a collection to similate the forms collection
    > moObjects.Add oAsNew
    >
    > ' Don't need to Set oAsNew = Nothing since VB will do it for you.
    >End Sub
    >
    >
    >--
    >~~~
    >C'Ya,
    >mrfelis
    >mrfelis@yahoo.NOSPAM.com
    >just remove the spam
    >John Perkins <perk_j@yahoo.com> wrote in message
    >news:39f20b06$2@news.devx.com...
    >>
    >> mrfelis,
    >>
    >>
    >> Try the code again. First comment out the set = nothing line. Click

    >Command1
    >> on Form1. Look at the results in Form2. Click Form2.Command1 to "Unload"
    >> the form. Click Form1.Command1 again.
    >>
    >> Now do the same with the Set Form2 = Nothing line not commented out.
    >>
    >> -John Perkins
    >>
    >>
    >> "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    >> >This is not a good example John. VB adds variables Form1 and Form2 to

    >the
    >> >project's symbol table (or whatever VB calls the symbol table). This

    can
    >> be
    >> >visualized by thinking of an BAS module in the project which contains

    the
    >> >following declarations:
    >> >
    >> >Public Form1 As New Form1
    >> >Public Form2 As New Form2
    >> >
    >> >As you add/remove/rename the forms through the IDE, VB will alter these
    >> >entries in the symbol table. So if you change Form2's name to frmTest,

    VB
    >> >will change the declaration to:
    >> >
    >> >Public Form1 As New Form1
    >> >Public frmTest As New frmTest
    >> >
    >> >Knowing this let's look at the code again (assuming the first click):
    >> >>
    >> >> Option Explicit
    >> >>
    >> >> Private Sub Command1_Click()
    >> >
    >> >At this point Form2 is nothing. The only way to see this is to put a
    >> >breakpoint on or before the next line and inspect Form2.
    >> >
    >> >> Form2.Init
    >> >VB creates a Form2 object, assigns the object to the global object

    >variable,
    >> >Form2, that VB created for you. The ref count for the object is increased

    >> by
    >> >1. Finally, VB calls the Init method of this object. The form is

    >initialized
    >> >soemwhere in this mess of code VB adds for you.
    >> >
    >> >> Form2.Show
    >> >Had Init not caused the Form2 object to load, VB would load the form

    for
    >> you
    >> >now as well as showing it. Once the form loads VB adds the form to the

    >Forms
    >> >Collection. This increases the ref count of the object by 1 again. So

    the
    >> >Form2 object's ref count is at least 2 at this point.
    >> >
    >> >> ' When the form is not set to nothing, it doesn't really
    >> >> ' go away. Try un-commenting this line and see the results.
    >> >> ' Set Form2 = Nothing
    >> >
    >> >In doing this, you release 1 reference to Form2 objects Ref Count by

    1.
    >> >Since the Forms collection has a reference to this Form2 object the

    >object
    >> >remains instantiated. The only way to get the Form2 object out of the

    >Forms
    >> >collection is to Unload it.
    >> >
    >> >> End Sub
    >> >>
    >> >
    >> >VB isn't really acting differently. MS just did some things behind the
    >> >scenes that (while violating good programming practice) make it easier

    to
    >> >get started doing things.
    >> >
    >> >--
    >> >~~~
    >> >C'Ya,
    >> >mrfelis
    >> >mrfelis@yahoo.NOSPAM.com
    >> >just remove the spam
    >> >
    >> >

    >>

    >
    >



  6. #36
    John Perkins Guest

    Re: Set MyObject=Nothing?


    Ok. Let me get this straight. You didn't analyze all the code. So, I'm guessing
    you still haven't run the code. Did you read the original intent of my post?
    Do you understand the very simple and specific point I was trying to make?
    Have you noticed that every response I've made to you has been to say that
    your replies are not relevant with what I was trying to say with the example.
    Do you see a connection here?

    I'm done talking to you.

    -John

    "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    >John, I never bothered to analyse Form2's code cause I don't need to, an
    >incomplete analysis isn't an incorrect analysis.
    >
    >
    >--
    >~~~
    >C'Ya,
    >mrfelis
    >mrfelis@yahoo.NOSPAM.com
    >just remove the spam
    >John Perkins <perk_j@yahoo.com> wrote in message
    >news:39f20c4d$1@news.devx.com...
    >>
    >> mrfelis,
    >>
    >> Also, your analysis of my code is incorrect anyway because you neglected
    >> to notice that I was unloading form2 in when you click Form2.Command1.
    >>
    >> Private Sub Command1_Click()
    >>
    >> Unload Me
    >>
    >> End Sub
    >>
    >>
    >> -John Perkins
    >>
    >> "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    >> >This is not a good example John. VB adds variables Form1 and Form2 to

    >the
    >> >project's symbol table (or whatever VB calls the symbol table). This

    can
    >> be
    >> >visualized by thinking of an BAS module in the project which contains

    the
    >> >following declarations:
    >> >
    >> >Public Form1 As New Form1
    >> >Public Form2 As New Form2
    >> >
    >> >As you add/remove/rename the forms through the IDE, VB will alter these
    >> >entries in the symbol table. So if you change Form2's name to frmTest,

    VB
    >> >will change the declaration to:
    >> >
    >> >Public Form1 As New Form1
    >> >Public frmTest As New frmTest
    >> >
    >> >Knowing this let's look at the code again (assuming the first click):
    >> >>
    >> >> Option Explicit
    >> >>
    >> >> Private Sub Command1_Click()
    >> >
    >> >At this point Form2 is nothing. The only way to see this is to put a
    >> >breakpoint on or before the next line and inspect Form2.
    >> >
    >> >> Form2.Init
    >> >VB creates a Form2 object, assigns the object to the global object

    >variable,
    >> >Form2, that VB created for you. The ref count for the object is increased

    >> by
    >> >1. Finally, VB calls the Init method of this object. The form is

    >initialized
    >> >soemwhere in this mess of code VB adds for you.
    >> >
    >> >> Form2.Show
    >> >Had Init not caused the Form2 object to load, VB would load the form

    for
    >> you
    >> >now as well as showing it. Once the form loads VB adds the form to the

    >Forms
    >> >Collection. This increases the ref count of the object by 1 again. So

    the
    >> >Form2 object's ref count is at least 2 at this point.
    >> >
    >> >> ' When the form is not set to nothing, it doesn't really
    >> >> ' go away. Try un-commenting this line and see the results.
    >> >> ' Set Form2 = Nothing
    >> >
    >> >In doing this, you release 1 reference to Form2 objects Ref Count by

    1.
    >> >Since the Forms collection has a reference to this Form2 object the

    >object
    >> >remains instantiated. The only way to get the Form2 object out of the

    >Forms
    >> >collection is to Unload it.
    >> >
    >> >> End Sub
    >> >>
    >> >
    >> >VB isn't really acting differently. MS just did some things behind the
    >> >scenes that (while violating good programming practice) make it easier

    to
    >> >get started doing things.
    >> >
    >> >--
    >> >~~~
    >> >C'Ya,
    >> >mrfelis
    >> >mrfelis@yahoo.NOSPAM.com
    >> >just remove the spam
    >> >
    >> >

    >>

    >
    >



  7. #37
    ralph Guest

    Re: Set MyObject=Nothing?


    Perhaps it would help if we appreciate why "Set MyObject=Nothing" was added
    to the language in the first place.

    Its real purpose, its only actual role, is to allow YOU as a programmer to
    "re-use" variable names and not orphan resources.

    Its role as a 'Memory Manager' doesn't go beyond helping the programmer to
    avoid shooting him/herself in the foot. It provides a good "hint" and nothing
    else. (Pun intended <smile>)

    If for example you have a variable that you have 'Set...New' to contain a
    particular reference and then you use 'Set...New' to change the variable
    to contain another reference, then YOU have lost a reference to that resource.
    VB may or may not take care of cleaning up the old reference depending on
    where the memory is allocated and what other resources are involved. The
    point is: It is not automatically a disaster if you do nothing. <pun>

    If however, you have a variable and set it to "Nothing" before reassignment
    VB has a better clue that this can be cleaned up.

    Also remember nothing happens on the line where you set the variable to "Nothing".
    "Nothing" does nothing to the reference count, "Nothing" reclaims no resources,
    unwinds no stacks, or deallocates anything. It is only a signal/flag/dirty
    bit/Hey! to VB. VB will use the information when doing its memory management/garbage
    cleanup. Sometimes that means changing the reference count, sometimes not,
    or sometimes doing ... well, Nothing!



  8. #38
    Dan Barclay Guest

    Re: Set MyObject=Nothing?

    Hi Andy,

    On Sat, 21 Oct 2000 19:39:10 +0100, "Andy Chevin"
    <yoshimura.freeserve.co.uk> wrote:

    <snip>

    >And what risk? This is how VB works. You can rely on it - there is no
    >evidence to the contrary.


    <snicker>

    Dan
    Language Stability is a *feature* I wish VB had!
    (#6)

  9. #39
    Andy Chevin Guest

    Re: Set MyObject=Nothing?

    Bob,

    > There is no right or wrong here and obviously neither side is going to be
    > convinced so this thread needs to die.
    > Set Thread=Nothing ' <g>
    >


    s'fine with me.

    It's obvious we aren't going to wrest that placebo from you <g>.

    Andy.



  10. #40
    mrfelis Guest

    Re: Set MyObject=Nothing?

    John Perkins <perk_j@yahoo.com> wrote in message
    news:39f45115$1@news.devx.com...
    >
    > Ok. Let me get this straight. You didn't analyze all the code. So, I'm

    guessing
    > you still haven't run the code. Did you read the original intent of my

    post?
    > Do you understand the very simple and specific point I was trying to make?
    > Have you noticed that every response I've made to you has been to say that
    > your replies are not relevant with what I was trying to say with the

    example.
    > Do you see a connection here?
    >
    > I'm done talking to you.
    >
    > -John

    Fine with me, since you won't provide a context for your example. (Yes I
    read the thread, and no I still don't see the point.)

    --
    ~~~
    C'Ya,
    mrfelis
    mrfelis@yahoo.NOSPAM.com
    just remove the spam
    >
    > "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    > >John, I never bothered to analyse Form2's code cause I don't need to, an
    > >incomplete analysis isn't an incorrect analysis.
    > >
    > >
    > >--
    > >~~~
    > >C'Ya,
    > >mrfelis
    > >mrfelis@yahoo.NOSPAM.com
    > >just remove the spam
    > >John Perkins <perk_j@yahoo.com> wrote in message
    > >news:39f20c4d$1@news.devx.com...
    > >>
    > >> mrfelis,
    > >>
    > >> Also, your analysis of my code is incorrect anyway because you

    neglected
    > >> to notice that I was unloading form2 in when you click Form2.Command1.
    > >>
    > >> Private Sub Command1_Click()
    > >>
    > >> Unload Me
    > >>
    > >> End Sub
    > >>
    > >>
    > >> -John Perkins
    > >>
    > >> "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    > >> >This is not a good example John. VB adds variables Form1 and Form2 to

    > >the
    > >> >project's symbol table (or whatever VB calls the symbol table). This

    > can
    > >> be
    > >> >visualized by thinking of an BAS module in the project which contains

    > the
    > >> >following declarations:
    > >> >
    > >> >Public Form1 As New Form1
    > >> >Public Form2 As New Form2
    > >> >
    > >> >As you add/remove/rename the forms through the IDE, VB will alter

    these
    > >> >entries in the symbol table. So if you change Form2's name to frmTest,

    > VB
    > >> >will change the declaration to:
    > >> >
    > >> >Public Form1 As New Form1
    > >> >Public frmTest As New frmTest
    > >> >
    > >> >Knowing this let's look at the code again (assuming the first click):
    > >> >>
    > >> >> Option Explicit
    > >> >>
    > >> >> Private Sub Command1_Click()
    > >> >
    > >> >At this point Form2 is nothing. The only way to see this is to put a
    > >> >breakpoint on or before the next line and inspect Form2.
    > >> >
    > >> >> Form2.Init
    > >> >VB creates a Form2 object, assigns the object to the global object

    > >variable,
    > >> >Form2, that VB created for you. The ref count for the object is

    increased
    > >> by
    > >> >1. Finally, VB calls the Init method of this object. The form is

    > >initialized
    > >> >soemwhere in this mess of code VB adds for you.
    > >> >
    > >> >> Form2.Show
    > >> >Had Init not caused the Form2 object to load, VB would load the form

    > for
    > >> you
    > >> >now as well as showing it. Once the form loads VB adds the form to the

    > >Forms
    > >> >Collection. This increases the ref count of the object by 1 again. So

    > the
    > >> >Form2 object's ref count is at least 2 at this point.
    > >> >
    > >> >> ' When the form is not set to nothing, it doesn't really
    > >> >> ' go away. Try un-commenting this line and see the results.
    > >> >> ' Set Form2 = Nothing
    > >> >
    > >> >In doing this, you release 1 reference to Form2 objects Ref Count by

    > 1.
    > >> >Since the Forms collection has a reference to this Form2 object the

    > >object
    > >> >remains instantiated. The only way to get the Form2 object out of the

    > >Forms
    > >> >collection is to Unload it.
    > >> >
    > >> >> End Sub
    > >> >>
    > >> >
    > >> >VB isn't really acting differently. MS just did some things behind the
    > >> >scenes that (while violating good programming practice) make it easier

    > to
    > >> >get started doing things.
    > >> >
    > >> >--
    > >> >~~~
    > >> >C'Ya,
    > >> >mrfelis
    > >> >mrfelis@yahoo.NOSPAM.com
    > >> >just remove the spam
    > >> >
    > >> >
    > >>

    > >
    > >

    >




  11. #41
    mrfelis Guest

    Re: Set MyObject=Nothing?

    > I'm done talking to you.
    >
    > -John

    Fine with me. Since you won't provide a clearer context for your example,
    (I'm still trying to understand what your point was. It can't be that VB
    does things differently with implicit form variables - I've pretty much beat
    that option to death.) I see no reason to keep the dialog going.


    --
    ~~~
    C'Ya,
    mrfelis
    mrfelis@yahoo.NOSPAM.com
    just remove the spam
    >
    > "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    > >John, I never bothered to analyse Form2's code cause I don't need to, an
    > >incomplete analysis isn't an incorrect analysis.
    > >
    > >
    > >--
    > >~~~
    > >C'Ya,
    > >mrfelis
    > >mrfelis@yahoo.NOSPAM.com
    > >just remove the spam
    > >John Perkins <perk_j@yahoo.com> wrote in message
    > >news:39f20c4d$1@news.devx.com...
    > >>
    > >> mrfelis,
    > >>
    > >> Also, your analysis of my code is incorrect anyway because you

    neglected
    > >> to notice that I was unloading form2 in when you click Form2.Command1.
    > >>
    > >> Private Sub Command1_Click()
    > >>
    > >> Unload Me
    > >>
    > >> End Sub
    > >>
    > >>
    > >> -John Perkins
    > >>
    > >> "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    > >> >This is not a good example John. VB adds variables Form1 and Form2 to

    > >the
    > >> >project's symbol table (or whatever VB calls the symbol table). This

    > can
    > >> be
    > >> >visualized by thinking of an BAS module in the project which contains

    > the
    > >> >following declarations:
    > >> >
    > >> >Public Form1 As New Form1
    > >> >Public Form2 As New Form2
    > >> >
    > >> >As you add/remove/rename the forms through the IDE, VB will alter

    these
    > >> >entries in the symbol table. So if you change Form2's name to frmTest,

    > VB
    > >> >will change the declaration to:
    > >> >
    > >> >Public Form1 As New Form1
    > >> >Public frmTest As New frmTest
    > >> >
    > >> >Knowing this let's look at the code again (assuming the first click):
    > >> >>
    > >> >> Option Explicit
    > >> >>
    > >> >> Private Sub Command1_Click()
    > >> >
    > >> >At this point Form2 is nothing. The only way to see this is to put a
    > >> >breakpoint on or before the next line and inspect Form2.
    > >> >
    > >> >> Form2.Init
    > >> >VB creates a Form2 object, assigns the object to the global object

    > >variable,
    > >> >Form2, that VB created for you. The ref count for the object is

    increased
    > >> by
    > >> >1. Finally, VB calls the Init method of this object. The form is

    > >initialized
    > >> >soemwhere in this mess of code VB adds for you.
    > >> >
    > >> >> Form2.Show
    > >> >Had Init not caused the Form2 object to load, VB would load the form

    > for
    > >> you
    > >> >now as well as showing it. Once the form loads VB adds the form to the

    > >Forms
    > >> >Collection. This increases the ref count of the object by 1 again. So

    > the
    > >> >Form2 object's ref count is at least 2 at this point.
    > >> >
    > >> >> ' When the form is not set to nothing, it doesn't really
    > >> >> ' go away. Try un-commenting this line and see the results.
    > >> >> ' Set Form2 = Nothing
    > >> >
    > >> >In doing this, you release 1 reference to Form2 objects Ref Count by

    > 1.
    > >> >Since the Forms collection has a reference to this Form2 object the

    > >object
    > >> >remains instantiated. The only way to get the Form2 object out of the

    > >Forms
    > >> >collection is to Unload it.
    > >> >
    > >> >> End Sub
    > >> >>
    > >> >
    > >> >VB isn't really acting differently. MS just did some things behind the
    > >> >scenes that (while violating good programming practice) make it easier

    > to
    > >> >get started doing things.
    > >> >
    > >> >--
    > >> >~~~
    > >> >C'Ya,
    > >> >mrfelis
    > >> >mrfelis@yahoo.NOSPAM.com
    > >> >just remove the spam
    > >> >
    > >> >
    > >>

    > >
    > >

    >






  12. #42
    Mark Alexander Bertenshaw Guest

    Re: Set MyObject=Nothing?


    Michael -

    "Michael Culley" <m_culley@one.net.au> wrote in message
    news:39f38fff$1@news.devx.com...

    <snip>

    > In one case I know of VB does not do the default behavoiur if you do it

    for
    > it. eg:
    >
    > Sub ABC
    > Dim x as long
    > Dim y as long
    > x=1
    > y=x
    > end sub
    >
    > In this case vb does not initialise x or y to zero because you initialise
    > them youself. I thought it may be the same for Set obj=Nothing but VB does
    > do it twice.
    >


    <snip>

    Are you sure about this? I was led to believe that VB always zeros the
    memory allocated on the stack. All you would be doing here is to overwrite
    the zeroes with your own values. Having said that, it looks as if VB.NET
    <will> do this by declaring it like this:

    Sub ABC
    Dim x as long = 1
    Dim y as long = 1
    end sub


    --
    Mark Alexander Bertenshaw
    Programmer/Analyst
    PrimeResponse
    Brentford
    UK




  13. #43
    Michael Culley Guest

    Re: Set MyObject=Nothing?


    Hi Mark,

    Do you remember an example I posted a couple of months ago where, in VB6,
    vb would consider 2 functions to be the same and optimise one of the functions
    out?

    The same applies here. Functions A and B will return the same address using
    addressof (when compiled). The only reason I have included function C is
    that VB kept optimising the functions down to just a return statement.

    Also, if you look at the functions decompiled you can see only one x=1 and
    y=0 in there.

    Michael Culley

    Put this in a module:

    Sub a()
    Dim x As Long
    Dim y As Long
    x = 1
    c x
    c y
    End Sub

    Sub b()
    Dim x As Long
    Dim y As Long
    y = 0
    x = 1
    c x
    c y
    End Sub

    Sub c(x As Long)
    MsgBox x
    End Sub

    Put this in a form

    Private Sub Form_Load()
    Me.Caption = AddOF(AddressOf a) & " " & AddOF(AddressOf b)
    End Sub

    Function AddOf(ByVal x As Long) As String
    AddOf = Hex$(x)
    End Function

    "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
    >
    >Michael -
    >
    >"Michael Culley" <m_culley@one.net.au> wrote in message
    >news:39f38fff$1@news.devx.com...
    >
    ><snip>
    >
    >> In one case I know of VB does not do the default behavoiur if you do it

    >for
    >> it. eg:
    >>
    >> Sub ABC
    >> Dim x as long
    >> Dim y as long
    >> x=1
    >> y=x
    >> end sub
    >>
    >> In this case vb does not initialise x or y to zero because you initialise
    >> them youself. I thought it may be the same for Set obj=Nothing but VB

    does
    >> do it twice.
    >>

    >
    ><snip>
    >
    >Are you sure about this? I was led to believe that VB always zeros the
    >memory allocated on the stack. All you would be doing here is to overwrite
    >the zeroes with your own values. Having said that, it looks as if VB.NET
    ><will> do this by declaring it like this:
    >
    >Sub ABC
    > Dim x as long = 1
    > Dim y as long = 1
    >end sub
    >
    >
    >--
    >Mark Alexander Bertenshaw
    >Programmer/Analyst
    >PrimeResponse
    >Brentford
    >UK
    >
    >
    >



  14. #44
    Mark Alexander Bertenshaw Guest

    Re: Set MyObject=Nothing?

    Michael -

    I remember this now!! It seems like ancient history <g>.

    However, I am missing something here. How do you get from VB6 optimising
    duplicate functions to VB6 initialising values other than zero on the stack?
    I understand that the VB6 compiler has optimised out the "y = 0" line; are
    you saying that "x = 1" is doing anything other than writing 1 over the 0 in
    "x"?

    Thanks,

    --
    Mark Alexander Bertenshaw
    Programmer/Analyst
    PrimeResponse
    Brentford
    UK

    "Michael Culley" <m_culley@one.net.au> wrote in message
    news:39f4b24d$1@news.devx.com...
    >
    > Hi Mark,
    >
    > Do you remember an example I posted a couple of months ago where, in VB6,
    > vb would consider 2 functions to be the same and optimise one of the

    functions
    > out?
    >
    > The same applies here. Functions A and B will return the same address

    using
    > addressof (when compiled). The only reason I have included function C is
    > that VB kept optimising the functions down to just a return statement.
    >
    > Also, if you look at the functions decompiled you can see only one x=1 and
    > y=0 in there.
    >
    > Michael Culley
    >
    > Put this in a module:
    >
    > Sub a()
    > Dim x As Long
    > Dim y As Long
    > x = 1
    > c x
    > c y
    > End Sub
    >
    > Sub b()
    > Dim x As Long
    > Dim y As Long
    > y = 0
    > x = 1
    > c x
    > c y
    > End Sub
    >
    > Sub c(x As Long)
    > MsgBox x
    > End Sub
    >
    > Put this in a form
    >
    > Private Sub Form_Load()
    > Me.Caption = AddOF(AddressOf a) & " " & AddOF(AddressOf b)
    > End Sub
    >
    > Function AddOf(ByVal x As Long) As String
    > AddOf = Hex$(x)
    > End Function
    >
    > "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
    > >
    > >Michael -
    > >
    > >"Michael Culley" <m_culley@one.net.au> wrote in message
    > >news:39f38fff$1@news.devx.com...
    > >
    > ><snip>
    > >
    > >> In one case I know of VB does not do the default behavoiur if you do it

    > >for
    > >> it. eg:
    > >>
    > >> Sub ABC
    > >> Dim x as long
    > >> Dim y as long
    > >> x=1
    > >> y=x
    > >> end sub
    > >>
    > >> In this case vb does not initialise x or y to zero because you

    initialise
    > >> them youself. I thought it may be the same for Set obj=Nothing but VB

    > does
    > >> do it twice.
    > >>

    > >
    > ><snip>
    > >
    > >Are you sure about this? I was led to believe that VB always zeros the
    > >memory allocated on the stack. All you would be doing here is to

    overwrite
    > >the zeroes with your own values. Having said that, it looks as if

    VB.NET
    > ><will> do this by declaring it like this:
    > >
    > >Sub ABC
    > > Dim x as long = 1
    > > Dim y as long = 1
    > >end sub
    > >
    > >
    > >--
    > >Mark Alexander Bertenshaw
    > >Programmer/Analyst
    > >PrimeResponse
    > >Brentford
    > >UK
    > >
    > >
    > >

    >




  15. #45
    Matthew Curland Guest

    Re: Set MyObject=Nothing?

    There is no point in setting a variable to Nothing when VB is about to do it
    anyway. VB still has to go behind your back and check up on you anyway, so
    you might as well let it. Adding these statements for clarity just as
    variables go out of scope simply to document that you are expecting these
    variables to go out of scope is pointless. Not only does it generate extra
    code, it also isn't reliable as a means of porting to other languages. After
    all, as is the case with most unecessary code, the correctness of the code
    is completely unverifiable because the app works the same with or without
    it. You don't leak if you put it in, and you don't leak if you do. If you
    rely on Set = Nothing statements for porting to another language, then you
    are basing the validity of the port on unverifiable code. If you want to add
    comments in this situation, then go ahead, but the code itself is a waste
    and does nothing more than bloat your exe (exe size does make a difference
    on performance).

    As for the pre-declared form variables, this is a completely different
    question than local variables. These are global variables. They go out of
    scope when the project terminates. If you want to clear them earlier, then
    you need an explicit Set = Nothing, just like you would if you wanted to
    release a local reference before the natural release sequence when the local
    goes out of scope. Of course, the original query didn't specify whether it
    was talking about locals or globals, but the vast majority of your
    references will be local, so I think this is what Peter was primarily after
    (I'm guessing, of course).

    There are two places Set = Nothing is useful:
    1) You use it at a time other than immediately before the object goes out of
    scope.
    2) You are recycling a variable and believe that freeing the current
    reference will release resource that could be used by a newly created
    reference. This is a rare case, but does happen on occasion. VB always
    evaluates the expression on the right of a Set statement before releasing a
    current reference on the left.

    If you want to clean up the pre-declared problem, then redeclare the
    variables in a .bas module without the New
    Public Form1 As Form1
    Public Form2 As Form2
    'etc

    This will strongly discourage you from using these variables (you'll get a
    runtime error when you same Form1.Show). If you instantiate forms with
    variables that have a more tightly scoped lifetime, as this encourages you
    to do, then the problem goes away.

    -Matt



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center