DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 4 of 5 FirstFirst ... 2345 LastLast
Results 46 to 60 of 65

Thread: Set MyObject=Nothing?

  1. #46
    John Perkins Guest

    Re: Set MyObject=Nothing?


    I put some sample code up earlier in this thread that demos this explicitly
    but had little luck trying to get (at least one person) to understand this
    point and/or run the code. Hopefully, your verbal explanation will work better.

    -John Perkins


    "Matthew Curland" <mattcur@microsoft.com> wrote:

    >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).



  2. #47
    John Perkins Guest

    Re: Set MyObject=Nothing?


    1. Some people on the thread said that you never need to Set o = Nothing.
    VB always does this for you.

    2. I provided an example where it does make a difference if you explicitly
    Set o = Nothing or not.

    How much clearer can you get?

    Okay that's it.

    -John


    "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    >> 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
    >> >> >
    >> >> >
    >> >>
    >> >
    >> >

    >>

    >
    >
    >
    >



  3. #48
    Michael Culley Guest

    Re: Set MyObject=Nothing?


    Matthew,

    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

    This doesn't work!

    Michael Culley

    "Matthew Curland" <mattcur@microsoft.com> wrote:
    >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
    >
    >



  4. #49
    Michael Culley Guest

    Re: Set MyObject=Nothing?


    Mark,

    Maybe I got off the track here, but if you remove the y=0 line the functions
    are the same, hence one is optimised out.

    >are
    >you saying that "x = 1" is doing anything other than writing 1 over the

    0 in
    >"x"?


    X=1 is overwriting whatever values was in memory, not necessarily 0. Because
    you initialise it, VB does not. From decompiling there is only one line setting
    a memory location to 0 and one line setting another memory location to 1.

    Michael Culley

    "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
    >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
    >> >
    >> >
    >> >

    >>

    >
    >



  5. #50
    Matthew Curland Guest

    Re: Set MyObject=Nothing?

    Upon further review: this doesn't work. The form variables seem to be a
    special case of predeclared identifiers. I could argue that it's a compiler
    error if the ambiguity isn't caught, but I have other things to do.

    This works if:
    1) The variables are declared in the same module that you use them.
    2) The predeclid or appobject attributes (which force the implicit variables
    to generate) are on typelib objects instead of on the project forms.

    In other words, it isn't very useful. However, this was only a crutch
    anyway, you can easily avoid using the construct. The most obvious case to
    avoid them is with modal forms, where I like the following (I'm sure this
    one works):
    With New Form1
    .Show vbModal
    End With

    -Matt

    > 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
    >
    > This doesn't work!
    >
    > Michael Culley





  6. #51
    David Hay Guest

    Re: Set MyObject=Nothing?


    "John Perkins" <perk_j@yahoo.com> wrote:
    >
    >1. Some people on the thread said that you never need to Set o = Nothing.
    >VB always does this for you.


    Not exactly. What people are saying is that you never need to Set MyObject
    = Nothing when MyObject is about to go out of scope.


    >2. I provided an example where it does make a difference if you explicitly
    >Set o = Nothing or not.


    Sure it makes a difference. But the example was not relevant to the issue
    of whether the variable was about to go out of scope. In the example, the
    global variable Form2 was not going out of scope at the end of the Form1.Command1_Click
    procedure, which is where the Set Form2 = Nothing is being added to the code.
    Unloading a form does not destroy it.



  7. #52
    Michael Culley Guest

    Re: Set MyObject=Nothing?


    Matthew,

    >I could argue that it's a compiler
    >error if the ambiguity isn't caught


    I don't think this is a compiler error. You can have duplicate variable declarations
    (not in the same module or function) and one will overwrite the other. Eg
    in a module Public x as long. This will be overwritten by dimming x in a
    function. VB itself must have ultimate power, except in the module that the
    variables are defined.

    Michael Culley

    "Matthew Curland" <mattcur@microsoft.com> wrote:
    >Upon further review: this doesn't work. The form variables seem to be a
    >special case of predeclared identifiers. I could argue that it's a compiler
    >error if the ambiguity isn't caught, but I have other things to do.
    >
    >This works if:
    >1) The variables are declared in the same module that you use them.
    >2) The predeclid or appobject attributes (which force the implicit variables
    >to generate) are on typelib objects instead of on the project forms.
    >
    >In other words, it isn't very useful. However, this was only a crutch
    >anyway, you can easily avoid using the construct. The most obvious case

    to
    >avoid them is with modal forms, where I like the following (I'm sure this
    >one works):
    >With New Form1
    > .Show vbModal
    >End With
    >
    >-Matt
    >
    >> 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
    >>
    >> This doesn't work!
    >>
    >> Michael Culley

    >
    >
    >



  8. #53
    Matthew Curland Guest

    Re: Set MyObject=Nothing?

    Oh boy, here we go (but I think we're saying the same thing).

    If you put Public g_x As Long in two modules and reference g_x directly from
    a third, you will get an ambiguous name error. Predeclared typelib
    identifiers are in a name resolution area lower than all modules (highest is
    local) because they can be overriden without ambiguity by a name in a
    module. No error in this case indicates that VB has an extra scoping level
    somewhere between 'same module' and 'different module'.

    Name resolution order:
    local
    same module
    predeclared vars in the project << I didn't know about this one
    different .bas module
    predeclared vars from typelibs << I knew about this one
    typelibs (prioritized in references dialog, no ambiguous name errors)

    Only typelib names have name shadowing associated with them, so you don't
    get ambiguities in the typelib space, but you should everywhere else. Since
    you can override all other names that VB references or generates with module
    level public vars, I was just surprised you couldn't do it in this case. (I
    guess some of the more obscure tools in the bag are bound to be a little
    rusty, because life without surprises isn't much fun.) -Matt



  9. #54
    Michael Culley Guest

    Re: Set MyObject=Nothing?


    Matthew,

    >(but I think we're saying the same thing).


    True, but I must give you credit for explaining it better than I did

    Michael Culley

    "Matthew Curland" <mattcur@microsoft.com> wrote:
    >Oh boy, here we go (but I think we're saying the same thing).
    >
    >If you put Public g_x As Long in two modules and reference g_x directly

    from
    >a third, you will get an ambiguous name error. Predeclared typelib
    >identifiers are in a name resolution area lower than all modules (highest

    is
    >local) because they can be overriden without ambiguity by a name in a
    >module. No error in this case indicates that VB has an extra scoping level
    >somewhere between 'same module' and 'different module'.
    >
    >Name resolution order:
    >local
    >same module
    >predeclared vars in the project << I didn't know about this one
    >different .bas module
    >predeclared vars from typelibs << I knew about this one
    >typelibs (prioritized in references dialog, no ambiguous name errors)
    >
    >Only typelib names have name shadowing associated with them, so you don't
    >get ambiguities in the typelib space, but you should everywhere else. Since
    >you can override all other names that VB references or generates with module
    >level public vars, I was just surprised you couldn't do it in this case.

    (I
    >guess some of the more obscure tools in the bag are bound to be a little
    >rusty, because life without surprises isn't much fun.) -Matt
    >
    >



  10. #55
    mrfelis Guest

    Re: Set MyObject=Nothing?

    John Perkins <perk_j@yahoo.com> wrote in message
    news:39f4c6d2$1@news.devx.com...

    >
    > 2. I provided an example where it does make a difference if you explicitly
    > Set o = Nothing or not.


    And the light bulb comes on! Sorry, I was getting thrown by that "different"
    and tring to see VB behaved differently. Let's never say I can see the
    forest for the trees!


    >1. Some people on the thread said that you never need to Set o = Nothing.
    >VB always does this for you.


    Could do the same thing with a local form variable and the Set o = nothing
    wouldn't be required.

    >
    > How much clearer can you get?
    >
    > Okay that's it.
    >

    I've taken a personal interest in this issue since I'm looking for amunition
    for changing coding standards at my shop. Currently we have the Set all
    objects = Nothing in place. I've come to question the reasoning and would
    like to get rid of it. We also lack a rule about closing all DAO Recordsets
    before setting them to nothing or to a different recordset.

    This makes me question the validity of the standards. I need all the
    amunition I can get.
    --
    ~~~
    C'Ya,
    mrfelis
    mrfelis@yahoo.NOSPAM.com
    just remove the spam

    > -John
    >
    >
    > "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    > >> 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
    > >> >> >
    > >> >> >
    > >> >>
    > >> >
    > >> >
    > >>

    > >
    > >
    > >
    > >

    >




  11. #56
    mrfelis Guest

    Re: Set MyObject=Nothing?

    Yes, he explained your point very well.

    --
    ~~~
    C'Ya,
    mrfelis
    mrfelis@yahoo.NOSPAM.com
    just remove the spam
    John Perkins <perk_j@yahoo.com> wrote in message
    news:39f4c4e2$1@news.devx.com...
    >
    > I put some sample code up earlier in this thread that demos this

    explicitly
    > but had little luck trying to get (at least one person) to understand this
    > point and/or run the code. Hopefully, your verbal explanation will work

    better.
    >
    > -John Perkins
    >
    >
    > "Matthew Curland" <mattcur@microsoft.com> wrote:
    >
    > >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).

    >




  12. #57
    John Perkins Guest

    Re: Set MyObject=Nothing?


    And apologies for my getting so exasperated trying to explain it.

    -John

    "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:
    >John Perkins <perk_j@yahoo.com> wrote in message
    >news:39f4c6d2$1@news.devx.com...
    >
    >>
    >> 2. I provided an example where it does make a difference if you explicitly
    >> Set o = Nothing or not.

    >
    >And the light bulb comes on! Sorry, I was getting thrown by that "different"
    >and tring to see VB behaved differently. Let's never say I can see the
    >forest for the trees!


  13. #58
    John Perkins Guest

    Re: Set MyObject=Nothing?


    The intent of my example (which was not a direct reponse to a post, but an
    aside) was to provide an example of why some people (not me) have got it
    in their heads that it is necessary to Set o = Nothing at the end of a procedure....
    i.e., because they see VB behave a certain way and then they make up a bogus
    general rule and use it everywhere.

    How else would you explain the fact that so many people Set o = Nothing all
    over the place when it is not needed? I can't think of another reason why
    people would have started doing that... unless Microsoft recommended it in
    their literature at some point. Did they?

    -John Perkins


    "David Hay" <david.hay@aspect.com.au> wrote:
    >
    >"John Perkins" <perk_j@yahoo.com> wrote:
    >>
    >>1. Some people on the thread said that you never need to Set o = Nothing.
    >>VB always does this for you.

    >
    >Not exactly. What people are saying is that you never need to Set MyObject
    >= Nothing when MyObject is about to go out of scope.
    >
    >
    >>2. I provided an example where it does make a difference if you explicitly
    >>Set o = Nothing or not.

    >
    >Sure it makes a difference. But the example was not relevant to the issue
    >of whether the variable was about to go out of scope. In the example, the
    >global variable Form2 was not going out of scope at the end of the Form1.Command1_Click
    >procedure, which is where the Set Form2 = Nothing is being added to the

    code.
    > Unloading a form does not destroy it.
    >
    >



  14. #59
    Anthony Jones Guest

    Re: Set MyObject=Nothing?

    Ralph,

    Which version of VB we talk'in here???


    --
    Anthony Jones
    Nuesoft Ltd




  15. #60
    Mark Alexander Bertenshaw Guest

    Re: Set MyObject=Nothing?

    Michael -

    Realisation has dawned <g>. I think I was at cross-purposes.
    You were saying that in:

    Private Sub A()
    Dim x As Integer

    <behind the scenes, VB makes x = 0>

    x = 0 <------ this line is optimised out.

    .....

    End Sub


    And I was thinking you were implying:


    Private Sub B()
    Dim y As Integer

    <behind the scenes, VB makes y = 0> <----- this process is
    optimised out.

    y = 1

    .....

    End Sub


    Hope this makes sense!


    --
    Mark Alexander Bertenshaw
    Programmer/Analyst
    PrimeResponse
    Brentford
    UK
    "Michael Culley" <m_culley@one.net.au> wrote in message
    news:39f4cd1d$1@news.devx.com...
    >
    > Mark,
    >
    > Maybe I got off the track here, but if you remove the y=0 line the

    functions
    > are the same, hence one is optimised out.
    >
    > >are
    > >you saying that "x = 1" is doing anything other than writing 1 over the

    > 0 in
    > >"x"?

    >
    > X=1 is overwriting whatever values was in memory, not necessarily 0.

    Because
    > you initialise it, VB does not. From decompiling there is only one line

    setting
    > a memory location to 0 and one line setting another memory location to 1.
    >
    > Michael Culley
    >
    > "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
    > >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
    > >> >
    > >> >
    > >> >
    > >>

    > >
    > >

    >




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