CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 2 FirstFirst 12
Results 16 to 24 of 24
  1. #16
    Join Date
    Aug 2006
    Posts
    145

    Re: Not actually a problem...

    Quote Originally Posted by WoF
    But to the last observation of hensa:
    I noticed this, too, last recently and was also a little perplexed. I would have expected the variables of a form to loose all their contents when the form got unloaded, but it seems not to be the case, indeed.

    It seems that a form, once loaded, is kept in a "cache" or something that it is present already when it has to be loaded again. It is as if it was only hidden, but gave a call to the Form_Unload() .
    This gave me a headache recently when I didn't know how a form's variable would remember a certain value after been unloaded and then been shown again. Is that behaviour documented, does anybody know?
    Mentioning this ties everything together very nicely.

    When you unload a named form (ie not instantiated with Set F = New Form1) a reference still exists to the object and as such the memory is not released. When you next load the object those variables that have not fallen out of scope will have their previous values preserved (ie. module-level variables).

    You can overcome this by setting the form reference to nothing: e.g
    Code:
    ' Inside Form1
    
    ' Assuming Form1 was loaded as:
    ' Load Form1
    'not
    'Set F = New Form1
    'Load F
    
    Private Sub Form_Unload(Cancel As Integer)
        Set Form1 = Nothing
    End Sub
    or you could also do this outside the form after unloading, or before you reload it.

    The reason you don't get any error when you next load the form (following the Set Form1 = Nothing) is the the form is essentially declared as Dim Form1 As New Form1 (if you get what I mean).

    Every time an object reference declared is used, VB checks to see if the object exists and if not, creates it. I saw comments above saying there's no difference in speed, but that's got to be the way it does it.
    Code:
    Dim col As New Collection
    
    Private Sub Command1_Click()
        Debug.Print ObjPtr(col)
        Debug.Print ObjPtr(col)
        Set col = Nothing
        Debug.Print ObjPtr(col)
    End Sub
    anyway, that's my two pennyworth, sorry if I've gone over anything already mentioned. That's the way I understand it - correct me if I'm wrong
    Last edited by bushmobile; August 9th, 2007 at 04:08 PM.

  2. #17
    Join Date
    Mar 2005
    Location
    Vienna, Austria
    Posts
    4,538

    Re: Not actually a problem...

    Quote Originally Posted by dglienna
    I had no problems with Office XP db's. Haven't tried Office 07 yet
    I'm nearly sure this isn't really a problem of office 2003 but it maybe is more exact about still living objects in running the code and this way maybe doesn't dispose objects which aren't disposed by the programmer and this way access doesn't close, while access 2000 and earlier may have disposed all the objects which havn't been set to nothing at programs end automatically.
    But thats only my assumption.
    Jonny Poet

    To be Alive is depending on the willingsness to help others and also to permit others to help you. So lets be alive. !
    Using Code Tags makes the difference: Code is easier to read, so its easier to help. Do it like this: [CODE] Put Your Code here [/code]
    If anyone felt he has got help, show it in rating the post.
    Also dont forget to set a post which is fully answered to 'resolved'. For more details look to FAQ's about Forum Usage. BTW I'm using Framework 3.5 and you ?
    My latest articles :
    Creating a Dockable Panel-Controlmanager Using C#, Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7

  3. #18
    Join Date
    Jul 2006
    Location
    Germany
    Posts
    3,725

    Re: Not actually a problem...

    To Bushmobiles comments about Forms:
    So there seems to be an automatic global variable "Form1" which is a reference to the form Form1 which is not freed when Form1 is unloaded... strange but seems to be true by evidence.

    Also strange, the collection example. The Set col = Nothing does not destroy the object as could be seen by printing. But you could assign a new collection to it: Set col = New Collection. It will replace the first one and then seems to stay persistent like the one before.

    If there is really some additional check routines added by the compiler, they must be in the assignment procedure, because every other performance of the object is not inflicted by it's type of creation.

    So at least I can make sure, there's no objection against using a globally declared Public FSO as New FileSystemObject when I want to peruse it throughout the program and have no intention whatsoever to destroy it until quitting the app. Right?

  4. #19
    Join Date
    Jan 2006
    Location
    Fox Lake, IL
    Posts
    15,007

    Re: Not actually a problem...

    I suppose it would be open thruout. I always prefer to set and destroy in each section, but I add the DIM in there as well.

    Global may be quicker if you open it dozens of times. Not sure.

    I have had problems with all versions of Office, until RD (@vbf) explained how things worked. Since then, no problems. (Except with PP )
    David

    CodeGuru Article: Bound Controls are Evil-VB6
    2013 Samples: MS CODE Samples

    CodeGuru Reviewer
    2006 Dell CSP
    2006, 2007 & 2008 MVP Visual Basic
    If your question has been answered satisfactorily, and it has been helpful, then, please, Rate this Post!

  5. #20
    Join Date
    Aug 2006
    Posts
    145

    Re: Not actually a problem...

    Quote Originally Posted by WoF
    Also strange, the collection example. The Set col = Nothing does not destroy the object as could be seen by printing. But you could assign a new collection to it: Set col = New Collection. It will replace the first one and then seems to stay persistent like the one before.
    the Set col = Nothing does release the memory, but when we use the reference again (passing it to ObjPtr) it gets re-instantiated - hence the memory address is different.

    i.e. compare it to
    Code:
    Dim col As Collection
    
    Private Sub Command1_Click()
        Set col = New Collection
        Debug.Print ObjPtr(col)
        Debug.Print ObjPtr(col)
        Set col = Nothing
        Debug.Print ObjPtr(col) '0
    End Sub

  6. #21
    Join Date
    Mar 2005
    Location
    Vienna, Austria
    Posts
    4,538

    Re: Not actually a problem...

    Quote Originally Posted by dglienna
    ...I have had problems with all versions of Office, until RD (@vbf) explained
    Who or what is RD please ? something to read ?
    Jonny Poet

    To be Alive is depending on the willingsness to help others and also to permit others to help you. So lets be alive. !
    Using Code Tags makes the difference: Code is easier to read, so its easier to help. Do it like this: [CODE] Put Your Code here [/code]
    If anyone felt he has got help, show it in rating the post.
    Also dont forget to set a post which is fully answered to 'resolved'. For more details look to FAQ's about Forum Usage. BTW I'm using Framework 3.5 and you ?
    My latest articles :
    Creating a Dockable Panel-Controlmanager Using C#, Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7

  7. #22
    Join Date
    Jan 2006
    Location
    Fox Lake, IL
    Posts
    15,007

    Re: Not actually a problem...

    DING!

    Robdog888 is a super moderator there, and a member here (who hasn't been around lately). He mods the Office Forums.

    He's helped me with a few things.
    David

    CodeGuru Article: Bound Controls are Evil-VB6
    2013 Samples: MS CODE Samples

    CodeGuru Reviewer
    2006 Dell CSP
    2006, 2007 & 2008 MVP Visual Basic
    If your question has been answered satisfactorily, and it has been helpful, then, please, Rate this Post!

  8. #23
    Join Date
    Mar 2005
    Location
    Vienna, Austria
    Posts
    4,538

    Re: Not actually a problem...

    Quote Originally Posted by dglienna
    DING!

    Robdog888 is a super moderator there, and a member here (who hasn't been around lately). He mods the Office Forums.

    He's helped me with a few things.
    thx
    Jonny Poet

    To be Alive is depending on the willingsness to help others and also to permit others to help you. So lets be alive. !
    Using Code Tags makes the difference: Code is easier to read, so its easier to help. Do it like this: [CODE] Put Your Code here [/code]
    If anyone felt he has got help, show it in rating the post.
    Also dont forget to set a post which is fully answered to 'resolved'. For more details look to FAQ's about Forum Usage. BTW I'm using Framework 3.5 and you ?
    My latest articles :
    Creating a Dockable Panel-Controlmanager Using C#, Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7

  9. #24
    Join Date
    Jul 2006
    Location
    Germany
    Posts
    3,725

    Re: Not actually a problem...

    @Bushmobile:
    I didn't notice a change of object address when it becomes reinstantiated. I tried this one:
    Code:
    dim col as new collection
    Private Sub Command2_Click()
      'Dim col As Collection
      Set col = New Collection
      Debug.Print "Set new"; ObjPtr(col)
      Set col = Nothing
      Debug.Print "Nothing"; ObjPtr(col)
      Debug.Print "--"
    End Sub
    When working with the local collection, the set to nothing will work. (But I get always the same address.) That's the debug.print after clicking twice:

    Set new 1991728
    Nothing 0
    --
    Set new 1991728
    Nothing 0
    --


    When I comment out the local col declaration and use the gloablly dimmed New Collection, the readout is:

    Set new 1996336
    Nothing 1996336
    --
    Set new 1991728
    Nothing 1991728
    --
    The referring by ObjPtr after the Set .. = Nothing reinstantiates obviously to the same address as before...


    But, however, now lot's of things are much clearer to me and I learned a lot about instantiating behaviour of VB.

    I thank you all for your input. I think I'll keep up with not setting objects to nothing and using a global FSO until I really need it differently , and - for sure - when I start using VBA objects of like word-docs or excel-sheets and whenever I'll have to use database objects...

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured