-
August 9th, 2007, 04:06 PM
#16
Re: Not actually a problem...
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.
-
August 9th, 2007, 06:17 PM
#17
Re: Not actually a problem...
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
-
August 10th, 2007, 11:20 AM
#18
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?
-
August 10th, 2007, 12:20 PM
#19
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 )
-
August 10th, 2007, 04:27 PM
#20
Re: Not actually a problem...
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
-
August 10th, 2007, 04:36 PM
#21
Re: Not actually a problem...
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
-
August 10th, 2007, 04:56 PM
#22
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.
-
August 11th, 2007, 03:09 AM
#23
Re: Not actually a problem...
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
-
August 13th, 2007, 08:59 AM
#24
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...
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|