I have a form that I programmatically generate some check boxes and labels on.
Later on when I want to draw the form with different data I want to clear
the previously created items and then put some new ones on.
In my code I am doing the following:
For Each ctrl In tpMain.Controls
If TypeOf (ctrl) Is CheckBox Then
If ctrl.Name.StartsWith("chkS") Then
ctrl.Visible = False
ctrl.Dispose()
End If
End If
End if
Next
What I am finding however is that in some cases controls that I know have
been affected by the above loop are staying on the form and not being made
invisible and then being disposed.
Is there a sure fire method of removing the controls rather than the dispose
method which presumably is not always removing the control for whatever
reason??
Siv
--
Martley, Near Worcester, UK
32  2746 
It would be much easier/simpler/reliable to have an extra form with the
extra controls. When a user needs to use the other set of controls -
instead of creating a whole new set of controls just bring up the extra
form and hide the main form - or if it even matters don't do anything
with the main form. Just leave it running.
Rich
*** Sent via Developersdex http://www.developersdex.com ***
I can't do that because the amount of check boxes differs dramatically
between redraws, there isn't a fixed layout. On one set of data I may only
need to show 2 check boxes on another ther may be 20 or 30. I am trying to
avoid the overhead of having thousands of controls on the forma nd only
create them as I need them and then when I have finished with them destroy
them again.
The problem i think is tha the dispose method doesn't always decide to
dispose when I want it to and is probably waiting for the system to quieten
down before actioning the request.
I really need a Ctrl.delete type comand.
Siv
--
Martley, Near Worcester, UK
"Rich P" wrote:
It would be much easier/simpler/reliable to have an extra form with the
extra controls. When a user needs to use the other set of controls -
instead of creating a whole new set of controls just bring up the extra
form and hide the main form - or if it even matters don't do anything
with the main form. Just leave it running.
Rich
*** Sent via Developersdex http://www.developersdex.com ***
Siv wrote:
I can't do that because the amount of check boxes differs dramatically
between redraws, there isn't a fixed layout. On one set of data I may only
need to show 2 check boxes on another ther may be 20 or 30. I am trying to
avoid the overhead of having thousands of controls on the forma nd only
create them as I need them and then when I have finished with them destroy
them again.
The problem i think is tha the dispose method doesn't always decide to
dispose when I want it to and is probably waiting for the system to quieten
down before actioning the request.
I really need a Ctrl.delete type comand.
Siv
Try this:
Create a panel onto which you will place your dynamic controls.
When you are finished with those controls, you should have a variable
for the original panel. Use the Clear method to get rid of all the
controls you created dynamically.
You now should have a blank panel upon which you can add controls with
new info.
Hope this helps
LS
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS") Then
tpMain.Controls.RemoveAt(_i)
_ctrl.Dispose()
End If
Next
"Siv" <Si*@discussions.microsoft.comwrote in message
news:EC**********************************@microsof t.com...
>I have a form that I programmatically generate some check boxes and labels
on.
Later on when I want to draw the form with different data I want to clear
the previously created items and then put some new ones on.
In my code I am doing the following:
For Each ctrl In tpMain.Controls
If TypeOf (ctrl) Is CheckBox Then
If ctrl.Name.StartsWith("chkS") Then
ctrl.Visible = False
ctrl.Dispose()
End If
End If
End if
Next
What I am finding however is that in some cases controls that I know have
been affected by the above loop are staying on the form and not being made
invisible and then being disposed.
Is there a sure fire method of removing the controls rather than the
dispose
method which presumably is not always removing the control for whatever
reason??
Siv
--
Martley, Near Worcester, UK
Lloyd,
Thanks for your response, these controls are already on a TabPage control
called tpMain.
When you say perform a clear, is that a method of the panel itself. Will
that clear all controls? There are a number of controls which are placed on
the TabPage at design time, would they be destroyed as well?
Interesteing idea though, I could certainly add a panel onto the TabPage in
the area where I want to display the check boxes and only add the controls
that are dynamically created to that panel.
Cheer,
Siv
--
Martley, Near Worcester, UK
"Lloyd Sheen" wrote:
Siv wrote:
I can't do that because the amount of check boxes differs dramatically
between redraws, there isn't a fixed layout. On one set of data I may only
need to show 2 check boxes on another ther may be 20 or 30. I am trying to
avoid the overhead of having thousands of controls on the forma nd only
create them as I need them and then when I have finished with them destroy
them again.
The problem i think is tha the dispose method doesn't always decide to
dispose when I want it to and is probably waiting for the system to quieten
down before actioning the request.
I really need a Ctrl.delete type comand.
Siv
Try this:
Create a panel onto which you will place your dynamic controls.
When you are finished with those controls, you should have a variable
for the original panel. Use the Clear method to get rid of all the
controls you created dynamically.
You now should have a blank panel upon which you can add controls with
new info.
Hope this helps
LS
Stephany,
Thanks for your reply. Can you explain why the additional command
tpMain.Controls.RemoveAt(_i)
will do the trick where just doing the dispose on its own does not?
I appreciate you gave me the answer, but I try to learn from my questions
here. Don't worry if you are too busy to reply, but if you do have time I
would appreciate it.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS") Then
tpMain.Controls.RemoveAt(_i)
_ctrl.Dispose()
End If
Next
"Siv" <Si*@discussions.microsoft.comwrote in message
news:EC**********************************@microsof t.com...
I have a form that I programmatically generate some check boxes and labels
on.
Later on when I want to draw the form with different data I want to clear
the previously created items and then put some new ones on.
In my code I am doing the following:
For Each ctrl In tpMain.Controls
If TypeOf (ctrl) Is CheckBox Then
If ctrl.Name.StartsWith("chkS") Then
ctrl.Visible = False
ctrl.Dispose()
End If
End If
End if
Next
What I am finding however is that in some cases controls that I know have
been affected by the above loop are staying on the form and not being made
invisible and then being disposed.
Is there a sure fire method of removing the controls rather than the
dispose
method which presumably is not always removing the control for whatever
reason??
Siv
--
Martley, Near Worcester, UK
Your problem was that, although you were 'disposing' the control, you were
not removing it from tpMain's collection of controls. Therefore you end up
with 'phantom' controls in tpMain's control collection.
Others might argue to the contrary, but I believe that the Dispose method of
a CheckBox control does nothing special, and it certainly will not remove
itself from it's parent collection.
Therefore the code can be further simplified to:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS") Then
tpMain.Controls.RemoveAt(_i)
Next
To save you asking, the reverse loop is to ensure that iterating on the
control collection is still viable even when one or more of the iteration
actually removes an element.
"Siv" <Si*@discussions.microsoft.comwrote in message
news:3A**********************************@microsof t.com...
Stephany,
Thanks for your reply. Can you explain why the additional command
tpMain.Controls.RemoveAt(_i)
will do the trick where just doing the dispose on its own does not?
I appreciate you gave me the answer, but I try to learn from my questions
here. Don't worry if you are too busy to reply, but if you do have time I
would appreciate it.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
>For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
_ctrl.Dispose()
End If
Next
"Siv" <Si*@discussions.microsoft.comwrote in message
news:EC**********************************@microso ft.com...
>I have a form that I programmatically generate some check boxes and
labels
on.
Later on when I want to draw the form with different data I want to
clear
the previously created items and then put some new ones on.
In my code I am doing the following:
For Each ctrl In tpMain.Controls
If TypeOf (ctrl) Is CheckBox Then
If ctrl.Name.StartsWith("chkS") Then
ctrl.Visible = False
ctrl.Dispose()
End If
End If
End if
Next
What I am finding however is that in some cases controls that I know
have
been affected by the above loop are staying on the form and not being
made
invisible and then being disposed.
Is there a sure fire method of removing the controls rather than the
dispose
method which presumably is not always removing the control for whatever
reason??
Siv
--
Martley, Near Worcester, UK
Stephany,
Thanks for clarifying, clearly I thought that to dispose of a control would
by inference remove it from the tpMain collection of controls. It's the old
story "never assume".
Thanks for your help.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
Your problem was that, although you were 'disposing' the control, you were
not removing it from tpMain's collection of controls. Therefore you end up
with 'phantom' controls in tpMain's control collection.
Others might argue to the contrary, but I believe that the Dispose method of
a CheckBox control does nothing special, and it certainly will not remove
itself from it's parent collection.
Therefore the code can be further simplified to:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS") Then
tpMain.Controls.RemoveAt(_i)
Next
To save you asking, the reverse loop is to ensure that iterating on the
control collection is still viable even when one or more of the iteration
actually removes an element.
"Siv" <Si*@discussions.microsoft.comwrote in message
news:3A**********************************@microsof t.com...
Stephany,
Thanks for your reply. Can you explain why the additional command
tpMain.Controls.RemoveAt(_i)
will do the trick where just doing the dispose on its own does not?
I appreciate you gave me the answer, but I try to learn from my questions
here. Don't worry if you are too busy to reply, but if you do have time I
would appreciate it.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
_ctrl.Dispose()
End If
Next
"Siv" <Si*@discussions.microsoft.comwrote in message
news:EC**********************************@microsof t.com...
I have a form that I programmatically generate some check boxes and
labels
on.
Later on when I want to draw the form with different data I want to
clear
the previously created items and then put some new ones on.
In my code I am doing the following:
For Each ctrl In tpMain.Controls
If TypeOf (ctrl) Is CheckBox Then
If ctrl.Name.StartsWith("chkS") Then
ctrl.Visible = False
ctrl.Dispose()
End If
End If
End if
Next
What I am finding however is that in some cases controls that I know
have
been affected by the above loop are staying on the form and not being
made
invisible and then being disposed.
Is there a sure fire method of removing the controls rather than the
dispose
method which presumably is not always removing the control for whatever
reason??
Siv
--
Martley, Near Worcester, UK
Siv wrote:
Lloyd,
Thanks for your response, these controls are already on a TabPage control
called tpMain.
When you say perform a clear, is that a method of the panel itself. Will
that clear all controls? There are a number of controls which are placed on
the TabPage at design time, would they be destroyed as well?
Interesteing idea though, I could certainly add a panel onto the TabPage in
the area where I want to display the check boxes and only add the controls
that are dynamically created to that panel.
Cheer,
Siv
Clear will clear all controls on the container (panel) so you would
loose other "non-dynamic" controls. Putting a panel on the tab page
would certainly work.
LS
Lloyd,
I am just trying Stephany's method as it involves less changes than yours,
but if her method doesn't solve teh problem I'll redesign the form slightly
and implement your idea.
Thanks again for your help.
Siv
--
Martley, Near Worcester, UK
"Lloyd Sheen" wrote:
Siv wrote:
Lloyd,
Thanks for your response, these controls are already on a TabPage control
called tpMain.
When you say perform a clear, is that a method of the panel itself. Will
that clear all controls? There are a number of controls which are placed on
the TabPage at design time, would they be destroyed as well?
Interesteing idea though, I could certainly add a panel onto the TabPage in
the area where I want to display the check boxes and only add the controls
that are dynamically created to that panel.
Cheer,
Siv
Clear will clear all controls on the container (panel) so you would
loose other "non-dynamic" controls. Putting a panel on the tab page
would certainly work.
LS
Siv,
Disposing is not a removing method or whateverf, it is just telling the GC
that it "can be" ready to clear up, like the GC does that automaticly when
it is really needed. Dispose is meant to put it at the garbage. As anology,
some people are the whole day busy with cleaning up there desktop (putting
it in the trash bin, which still will not be direct emptied), others do that
once a day or/and some when that is needed.
As it is about forms, you can see in your designer part of the class
(versions before 2005 normal in the class) the implementing of IDisposable
of a form.
As long as an object is referenced by something (like on a form with
controls.add) it will not be cleared as long as that has a reference,
whatever other method you call (including dispose), mostly is that by clear
them all in one time or by removing them one by one.
Cor
"Siv" <Si*@discussions.microsoft.comschreef in bericht
news:EB**********************************@microsof t.com...
Stephany,
Thanks for clarifying, clearly I thought that to dispose of a control
would
by inference remove it from the tpMain collection of controls. It's the
old
story "never assume".
Thanks for your help.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
>Your problem was that, although you were 'disposing' the control, you
were
not removing it from tpMain's collection of controls. Therefore you end
up
with 'phantom' controls in tpMain's control collection.
Others might argue to the contrary, but I believe that the Dispose method
of
a CheckBox control does nothing special, and it certainly will not remove
itself from it's parent collection.
Therefore the code can be further simplified to:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
Next
To save you asking, the reverse loop is to ensure that iterating on the
control collection is still viable even when one or more of the iteration
actually removes an element.
"Siv" <Si*@discussions.microsoft.comwrote in message
news:3A**********************************@microso ft.com...
Stephany,
Thanks for your reply. Can you explain why the additional command
tpMain.Controls.RemoveAt(_i)
will do the trick where just doing the dispose on its own does not?
I appreciate you gave me the answer, but I try to learn from my
questions
here. Don't worry if you are too busy to reply, but if you do have time
I
would appreciate it.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
_ctrl.Dispose()
End If
Next
"Siv" <Si*@discussions.microsoft.comwrote in message
news:EC**********************************@microso ft.com...
I have a form that I programmatically generate some check boxes and
labels
on.
Later on when I want to draw the form with different data I want to
clear
the previously created items and then put some new ones on.
In my code I am doing the following:
For Each ctrl In tpMain.Controls
If TypeOf (ctrl) Is CheckBox Then
If ctrl.Name.StartsWith("chkS") Then
ctrl.Visible = False
ctrl.Dispose()
End If
End If
End if
Next
What I am finding however is that in some cases controls that I know
have
been affected by the above loop are staying on the form and not
being
made
invisible and then being disposed.
Is there a sure fire method of removing the controls rather than the
dispose
method which presumably is not always removing the control for
whatever
reason??
Siv
--
Martley, Near Worcester, UK
Cor,
I'm sure it is useless to argue with you, but it is misleading to say
that the purpose of Dispose is to tell the GC that the object " 'can
be' ready to clear up".
The purpose if Dispose is to release unmanaged resources. For
Controls, that would mostly be the Windows handle for the associated
Windows control. If you fail to call Dispose for a Control that has
allocated a Windows handle, then the handle might no be freed for a
very long time, and if you do this enough times you might run out of
Windows handles.
On Tue, 5 Aug 2008 06:47:35 +0200, "Cor Ligthert[MVP]"
<no************@planet.nlwrote:
>Siv,
Disposing is not a removing method or whateverf, it is just telling the GC
that it "can be" ready to clear up, like the GC does that automaticly when
it is really needed. Dispose is meant to put it at the garbage. As anology,
some people are the whole day busy with cleaning up there desktop (putting
it in the trash bin, which still will not be direct emptied), others do that
once a day or/and some when that is needed.
As it is about forms, you can see in your designer part of the class
(versions before 2005 normal in the class) the implementing of IDisposable
of a form.
As long as an object is referenced by something (like on a form with
controls.add) it will not be cleared as long as that has a reference,
whatever other method you call (including dispose), mostly is that by clear
them all in one time or by removing them one by one.
Cor
"Siv" <Si*@discussions.microsoft.comschreef in bericht
news:EB**********************************@microso ft.com...
>Stephany,
Thanks for clarifying, clearly I thought that to dispose of a control
would
by inference remove it from the tpMain collection of controls. It's the
old
story "never assume".
Thanks for your help.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
>>Your problem was that, although you were 'disposing' the control, you
were
not removing it from tpMain's collection of controls. Therefore you end
up
with 'phantom' controls in tpMain's control collection.
Others might argue to the contrary, but I believe that the Dispose method
of
a CheckBox control does nothing special, and it certainly will not remove
itself from it's parent collection.
Therefore the code can be further simplified to:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
Next
To save you asking, the reverse loop is to ensure that iterating on the
control collection is still viable even when one or more of the iteration
actually removes an element.
"Siv" <Si*@discussions.microsoft.comwrote in message
news:3A**********************************@micros oft.com...
Stephany,
Thanks for your reply. Can you explain why the additional command
tpMain.Controls.RemoveAt(_i)
will do the trick where just doing the dispose on its own does not?
I appreciate you gave me the answer, but I try to learn from my
questions
here. Don't worry if you are too busy to reply, but if you do have time
I
would appreciate it.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
_ctrl.Dispose()
End If
Next
"Siv" <Si*@discussions.microsoft.comwrote in message
news:EC**********************************@micros oft.com...
I have a form that I programmatically generate some check boxes and
labels
on.
Later on when I want to draw the form with different data I want to
clear
the previously created items and then put some new ones on.
In my code I am doing the following:
For Each ctrl In tpMain.Controls
If TypeOf (ctrl) Is CheckBox Then
If ctrl.Name.StartsWith("chkS") Then
ctrl.Visible = False
ctrl.Dispose()
End If
End If
End if
Next
What I am finding however is that in some cases controls that I know
have
been affected by the above loop are staying on the form and not
being
made
invisible and then being disposed.
Is there a sure fire method of removing the controls rather than the
dispose
method which presumably is not always removing the control for
whatever
reason??
Siv
--
Martley, Near Worcester, UK
Jack,
Absolute true, I had it first in my message but was afraid that it would
create to much confusion (and discussion). I normally try to write that part
exactly like you do, and it is very important in the case there are
unmanaged resources used. Which is AFAIK by instance not the fact "in"
controls. (but can be used in objects that controls are using).
I have seen it so much written in the context like I did now, so I did that
a bit like that to avoid a discussion. Normally I don't use that because it
is for me really a minor aspect to take action to clear 100bytes memory a
little bit quicker while I have 1Gb not used.
Cor
"Jack Jackson" <jj******@cinnovations.netschreef in bericht
news:6t********************************@4ax.com...
Cor,
I'm sure it is useless to argue with you, but it is misleading to say
that the purpose of Dispose is to tell the GC that the object " 'can
be' ready to clear up".
The purpose if Dispose is to release unmanaged resources. For
Controls, that would mostly be the Windows handle for the associated
Windows control. If you fail to call Dispose for a Control that has
allocated a Windows handle, then the handle might no be freed for a
very long time, and if you do this enough times you might run out of
Windows handles.
On Tue, 5 Aug 2008 06:47:35 +0200, "Cor Ligthert[MVP]"
<no************@planet.nlwrote:
>>Siv,
Disposing is not a removing method or whateverf, it is just telling the GC
that it "can be" ready to clear up, like the GC does that automaticly when
it is really needed. Dispose is meant to put it at the garbage. As
anology,
some people are the whole day busy with cleaning up there desktop (putting
it in the trash bin, which still will not be direct emptied), others do
that
once a day or/and some when that is needed.
As it is about forms, you can see in your designer part of the class
(versions before 2005 normal in the class) the implementing of IDisposable
of a form.
As long as an object is referenced by something (like on a form with
controls.add) it will not be cleared as long as that has a reference,
whatever other method you call (including dispose), mostly is that by
clear
them all in one time or by removing them one by one.
Cor
"Siv" <Si*@discussions.microsoft.comschreef in bericht
news:EB**********************************@micros oft.com...
>>Stephany,
Thanks for clarifying, clearly I thought that to dispose of a control
would
by inference remove it from the tpMain collection of controls. It's the
old
story "never assume".
Thanks for your help.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
Your problem was that, although you were 'disposing' the control, you
were
not removing it from tpMain's collection of controls. Therefore you
end
up
with 'phantom' controls in tpMain's control collection.
Others might argue to the contrary, but I believe that the Dispose
method
of
a CheckBox control does nothing special, and it certainly will not
remove
itself from it's parent collection.
Therefore the code can be further simplified to:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
Next
To save you asking, the reverse loop is to ensure that iterating on the
control collection is still viable even when one or more of the
iteration
actually removes an element.
"Siv" <Si*@discussions.microsoft.comwrote in message
news:3A**********************************@micro soft.com...
Stephany,
Thanks for your reply. Can you explain why the additional command
tpMain.Controls.RemoveAt(_i)
will do the trick where just doing the dispose on its own does not?
I appreciate you gave me the answer, but I try to learn from my
questions
here. Don't worry if you are too busy to reply, but if you do have
time
I
would appreciate it.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso
_ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
_ctrl.Dispose()
End If
Next
"Siv" <Si*@discussions.microsoft.comwrote in message
news:EC**********************************@micro soft.com...
I have a form that I programmatically generate some check boxes and
labels
on.
Later on when I want to draw the form with different data I want
to
clear
the previously created items and then put some new ones on.
In my code I am doing the following:
For Each ctrl In tpMain.Controls
If TypeOf (ctrl) Is CheckBox Then
If ctrl.Name.StartsWith("chkS") Then
ctrl.Visible = False
ctrl.Dispose()
End If
End If
End if
Next
What I am finding however is that in some cases controls that I
know
have
been affected by the above loop are staying on the form and not
being
made
invisible and then being disposed.
Is there a sure fire method of removing the controls rather than
the
dispose
method which presumably is not always removing the control for
whatever
reason??
Siv
--
Martley, Near Worcester, UK
Jack,
Maybe should I have added this piece of code that is created by most
designers.
Which AFAIK is done by instance at every close of a form.
\\\
'Form overrides dispose to clean up the component list.
<System.Diagnostics.DebuggerNonUserCode()_
Protected Overrides Sub Dispose(ByVal disposing As Boolean)
Try
If disposing AndAlso components IsNot Nothing Then
components.Dispose()
End If
Finally
MyBase.Dispose(disposing)
End Try
End Sub
///
Cor
"Jack Jackson" <jj******@cinnovations.netschreef in bericht
news:6t********************************@4ax.com...
Cor,
I'm sure it is useless to argue with you, but it is misleading to say
that the purpose of Dispose is to tell the GC that the object " 'can
be' ready to clear up".
The purpose if Dispose is to release unmanaged resources. For
Controls, that would mostly be the Windows handle for the associated
Windows control. If you fail to call Dispose for a Control that has
allocated a Windows handle, then the handle might no be freed for a
very long time, and if you do this enough times you might run out of
Windows handles.
On Tue, 5 Aug 2008 06:47:35 +0200, "Cor Ligthert[MVP]"
<no************@planet.nlwrote:
>>Siv,
Disposing is not a removing method or whateverf, it is just telling the GC
that it "can be" ready to clear up, like the GC does that automaticly when
it is really needed. Dispose is meant to put it at the garbage. As
anology,
some people are the whole day busy with cleaning up there desktop (putting
it in the trash bin, which still will not be direct emptied), others do
that
once a day or/and some when that is needed.
As it is about forms, you can see in your designer part of the class
(versions before 2005 normal in the class) the implementing of IDisposable
of a form.
As long as an object is referenced by something (like on a form with
controls.add) it will not be cleared as long as that has a reference,
whatever other method you call (including dispose), mostly is that by
clear
them all in one time or by removing them one by one.
Cor
"Siv" <Si*@discussions.microsoft.comschreef in bericht
news:EB**********************************@micros oft.com...
>>Stephany,
Thanks for clarifying, clearly I thought that to dispose of a control
would
by inference remove it from the tpMain collection of controls. It's the
old
story "never assume".
Thanks for your help.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
Your problem was that, although you were 'disposing' the control, you
were
not removing it from tpMain's collection of controls. Therefore you
end
up
with 'phantom' controls in tpMain's control collection.
Others might argue to the contrary, but I believe that the Dispose
method
of
a CheckBox control does nothing special, and it certainly will not
remove
itself from it's parent collection.
Therefore the code can be further simplified to:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
Next
To save you asking, the reverse loop is to ensure that iterating on the
control collection is still viable even when one or more of the
iteration
actually removes an element.
"Siv" <Si*@discussions.microsoft.comwrote in message
news:3A**********************************@micro soft.com...
Stephany,
Thanks for your reply. Can you explain why the additional command
tpMain.Controls.RemoveAt(_i)
will do the trick where just doing the dispose on its own does not?
I appreciate you gave me the answer, but I try to learn from my
questions
here. Don't worry if you are too busy to reply, but if you do have
time
I
would appreciate it.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso
_ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
_ctrl.Dispose()
End If
Next
"Siv" <Si*@discussions.microsoft.comwrote in message
news:EC**********************************@micro soft.com...
I have a form that I programmatically generate some check boxes and
labels
on.
Later on when I want to draw the form with different data I want
to
clear
the previously created items and then put some new ones on.
In my code I am doing the following:
For Each ctrl In tpMain.Controls
If TypeOf (ctrl) Is CheckBox Then
If ctrl.Name.StartsWith("chkS") Then
ctrl.Visible = False
ctrl.Dispose()
End If
End If
End if
Next
What I am finding however is that in some cases controls that I
know
have
been affected by the above loop are staying on the form and not
being
made
invisible and then being disposed.
Is there a sure fire method of removing the controls rather than
the
dispose
method which presumably is not always removing the control for
whatever
reason??
Siv
--
Martley, Near Worcester, UK
Jack,
And the last one I hope, I have forever discussion with people who tell that
you should call the method dispose as soon as that method is derived from
components (which has a dispose method).
It is simple not true, a simple dataset is an array of references, nothing
more and has not any unmanaged resource, but it derives from components. http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx
As well is often forgotten that like "using" the method "close" often calls
the dispose (like by the dataconnection).
Cor
"Jack Jackson" <jj******@cinnovations.netschreef in bericht
news:6t********************************@4ax.com...
Cor,
I'm sure it is useless to argue with you, but it is misleading to say
that the purpose of Dispose is to tell the GC that the object " 'can
be' ready to clear up".
The purpose if Dispose is to release unmanaged resources. For
Controls, that would mostly be the Windows handle for the associated
Windows control. If you fail to call Dispose for a Control that has
allocated a Windows handle, then the handle might no be freed for a
very long time, and if you do this enough times you might run out of
Windows handles.
On Tue, 5 Aug 2008 06:47:35 +0200, "Cor Ligthert[MVP]"
<no************@planet.nlwrote:
>>Siv,
Disposing is not a removing method or whateverf, it is just telling the GC
that it "can be" ready to clear up, like the GC does that automaticly when
it is really needed. Dispose is meant to put it at the garbage. As
anology,
some people are the whole day busy with cleaning up there desktop (putting
it in the trash bin, which still will not be direct emptied), others do
that
once a day or/and some when that is needed.
As it is about forms, you can see in your designer part of the class
(versions before 2005 normal in the class) the implementing of IDisposable
of a form.
As long as an object is referenced by something (like on a form with
controls.add) it will not be cleared as long as that has a reference,
whatever other method you call (including dispose), mostly is that by
clear
them all in one time or by removing them one by one.
Cor
"Siv" <Si*@discussions.microsoft.comschreef in bericht
news:EB**********************************@micros oft.com...
>>Stephany,
Thanks for clarifying, clearly I thought that to dispose of a control
would
by inference remove it from the tpMain collection of controls. It's the
old
story "never assume".
Thanks for your help.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
Your problem was that, although you were 'disposing' the control, you
were
not removing it from tpMain's collection of controls. Therefore you
end
up
with 'phantom' controls in tpMain's control collection.
Others might argue to the contrary, but I believe that the Dispose
method
of
a CheckBox control does nothing special, and it certainly will not
remove
itself from it's parent collection.
Therefore the code can be further simplified to:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
Next
To save you asking, the reverse loop is to ensure that iterating on the
control collection is still viable even when one or more of the
iteration
actually removes an element.
"Siv" <Si*@discussions.microsoft.comwrote in message
news:3A**********************************@micro soft.com...
Stephany,
Thanks for your reply. Can you explain why the additional command
tpMain.Controls.RemoveAt(_i)
will do the trick where just doing the dispose on its own does not?
I appreciate you gave me the answer, but I try to learn from my
questions
here. Don't worry if you are too busy to reply, but if you do have
time
I
would appreciate it.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso
_ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
_ctrl.Dispose()
End If
Next
"Siv" <Si*@discussions.microsoft.comwrote in message
news:EC**********************************@micro soft.com...
I have a form that I programmatically generate some check boxes and
labels
on.
Later on when I want to draw the form with different data I want
to
clear
the previously created items and then put some new ones on.
In my code I am doing the following:
For Each ctrl In tpMain.Controls
If TypeOf (ctrl) Is CheckBox Then
If ctrl.Name.StartsWith("chkS") Then
ctrl.Visible = False
ctrl.Dispose()
End If
End If
End if
Next
What I am finding however is that in some cases controls that I
know
have
been affected by the above loop are staying on the form and not
being
made
invisible and then being disposed.
Is there a sure fire method of removing the controls rather than
the
dispose
method which presumably is not always removing the control for
whatever
reason??
Siv
--
Martley, Near Worcester, UK
Jack,
Should call the method is derived from compone I hope, I has a
discussion as a dispose as soon as the last one I has that you should
call that you should call that you should call that method dispose as
soon with people who tell that method dispose method). And that method
is derived from compone I have forever dispose as a discussion with
people who tell that you should call that metthod.
Nothing more and has nothing more an array of resource, a simple dataset
it derives from components. It is simple dataset is any unmanaged
references, not true, a simple dataset is simple dataset it derives from
components. It it derives from components. It is and has not true, but
is simple not trrue, http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx
Dataconnection). As well is often forgotten forgotten the
dataconnection). As well is often forgotten forgotten forgotten
forgotten the dispose (like by that like "using" that like by that like
by the method "close (like by the dataconnect
Cor
In bericht news:6t********************************@4ax.com... "jack
jackson" <jjack jack jackson" <jj******@cinnovations.netschreef in
bericht news:6t********************************@4ax.com... "jack jack ja*****@cinnovations.nnet>.
Cor,
I'm sure it is useless to argue with you, but it is misleading to say
that the purpose of Dispose is to tell the GC that the object " 'can
be' ready to clear up".
The purpose if Dispose is to release unmanaged resources. For
Controls, that would mostly be the Windows handle for the associated
Windows control. If you fail to call Dispose for a Control that has
allocated a Windows handle, then the handle might no be freed for a
very long time, and if you do this enough times you might run out of
Windows handles.
On Tue, 5 Aug 2008 06:47:35 +0200, "Cor Ligthert[MVP]"
<no************@planet.nlwrote:
>>Siv,
Disposing is not a removing method or whateverf, it is just telling the GC
that it "can be" ready to clear up, like the GC does that automaticly when
it is really needed. Dispose is meant to put it at the garbage. As
anology,
some people are the whole day busy with cleaning up there desktop (putting
it in the trash bin, which still will not be direct emptied), others do
that
once a day or/and some when that is needed.
As it is about forms, you can see in your designer part of the class
(versions before 2005 normal in the class) the implementing of IDisposable
of a form.
As long as an object is referenced by something (like on a form with
controls.add) it will not be cleared as long as that has a reference,
whatever other method you call (including dispose), mostly is that by
clear
them all in one time or by removing them one by one.
Cor
"Siv" <Si*@discussions.microsoft.comschreef in bericht
news:EB**********************************@micros oft.com...
>>Stephany,
Thanks for clarifying, clearly I thought that to dispose of a control
would
by inference remove it from the tpMain collection of controls. It's the
old
story "never assume".
Thanks for your help.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
Your problem was that, although you were 'disposing' the control, you
were
not removing it from tpMain's collection of controls. Therefore you
end
up
with 'phantom' controls in tpMain's control collection.
Others might argue to the contrary, but I believe that the Dispose
method
of
a CheckBox control does nothing special, and it certainly will not
remove
itself from it's parent collection.
Therefore the code can be further simplified to:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
Next
To save you asking, the reverse loop is to ensure that iterating on the
control collection is still viable even when one or more of the
iteration
actually removes an element.
"Siv" <Si*@discussions.microsoft.comwrote in message
news:3A**********************************@micro soft.com...
Stephany,
Thanks for your reply. Can you explain why the additional command
tpMain.Controls.RemoveAt(_i)
will do the trick where just doing the dispose on its own does not?
I appreciate you gave me the answer, but I try to learn from my
questions
here. Don't worry if you are too busy to reply, but if you do have
time
I
would appreciate it.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso
_ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
_ctrl.Dispose()
End If
Next
"Siv" <Si*@discussions.microsoft.comwrote in message
news:EC**********************************@micro soft.com...
I have a form that I programmatically generate some check boxes and
labels
on.
Later on when I want to draw the form with different data I want
to
clear
the previously created items and then put some new ones on.
In my code I am doing the following:
For Each ctrl In tpMain.Controls
If TypeOf (ctrl) Is CheckBox Then
If ctrl.Name.StartsWith("chkS") Then
ctrl.Visible = False
ctrl.Dispose()
End If
End If
End if
Next
What I am finding however is that in some cases controls that I
know
have
been affected by the above loop are staying on the form and not
being
made
invisible and then being disposed.
Is there a sure fire method of removing the controls rather than
the
dispose
method which presumably is not always removing the control for
whatever
reason??
Siv
--
Martley, Near Worcester, UK
Stephany,
Your method worked a treat and my form now looks as it should between each
redraw. I noticed the conversation below between Cor and Jack and that is
flushing out some interesting debate about the merits of dispose.
I definitely agree with Jack's assertion that you really do need to include
the dispose method, otherwise on a form like mine where the same tab page is
being used over and over with potentially thousands of controls used each
time the tab page is populated with checkboxes would lead to some for of
resource problem if run long enough.
Thanks again for your help, the program now works as it should and I have
learnt something new.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
Your problem was that, although you were 'disposing' the control, you were
not removing it from tpMain's collection of controls. Therefore you end up
with 'phantom' controls in tpMain's control collection.
Others might argue to the contrary, but I believe that the Dispose method of
a CheckBox control does nothing special, and it certainly will not remove
itself from it's parent collection.
Therefore the code can be further simplified to:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS") Then
tpMain.Controls.RemoveAt(_i)
Next
To save you asking, the reverse loop is to ensure that iterating on the
control collection is still viable even when one or more of the iteration
actually removes an element.
"Siv" <Si*@discussions.microsoft.comwrote in message
news:3A**********************************@microsof t.com...
Stephany,
Thanks for your reply. Can you explain why the additional command
tpMain.Controls.RemoveAt(_i)
will do the trick where just doing the dispose on its own does not?
I appreciate you gave me the answer, but I try to learn from my questions
here. Don't worry if you are too busy to reply, but if you do have time I
would appreciate it.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
_ctrl.Dispose()
End If
Next
"Siv" <Si*@discussions.microsoft.comwrote in message
news:EC**********************************@microsof t.com...
I have a form that I programmatically generate some check boxes and
labels
on.
Later on when I want to draw the form with different data I want to
clear
the previously created items and then put some new ones on.
In my code I am doing the following:
For Each ctrl In tpMain.Controls
If TypeOf (ctrl) Is CheckBox Then
If ctrl.Name.StartsWith("chkS") Then
ctrl.Visible = False
ctrl.Dispose()
End If
End If
End if
Next
What I am finding however is that in some cases controls that I know
have
been affected by the above loop are staying on the form and not being
made
invisible and then being disposed.
Is there a sure fire method of removing the controls rather than the
dispose
method which presumably is not always removing the control for whatever
reason??
Siv
--
Martley, Near Worcester, UK
Cor,
Thanks for your help on this. My mistake as mentioned above when Stephany
put me straight was that I asumed that if the dispose method was called, that
would effectively make the parent (in this case a tabpage) automatically
remove the control from its collection.
Now I underdtand that this isn't the case my understanding of how Dispose
operates is improved. Thanks for your help with this.
Siv
--
Martley, Near Worcester, UK
"Cor Ligthert[MVP]" wrote:
Siv,
Disposing is not a removing method or whateverf, it is just telling the GC
that it "can be" ready to clear up, like the GC does that automaticly when
it is really needed. Dispose is meant to put it at the garbage. As anology,
some people are the whole day busy with cleaning up there desktop (putting
it in the trash bin, which still will not be direct emptied), others do that
once a day or/and some when that is needed.
As it is about forms, you can see in your designer part of the class
(versions before 2005 normal in the class) the implementing of IDisposable
of a form.
As long as an object is referenced by something (like on a form with
controls.add) it will not be cleared as long as that has a reference,
whatever other method you call (including dispose), mostly is that by clear
them all in one time or by removing them one by one.
Cor
"Siv" <Si*@discussions.microsoft.comschreef in bericht
news:EB**********************************@microsof t.com...
Stephany,
Thanks for clarifying, clearly I thought that to dispose of a control
would
by inference remove it from the tpMain collection of controls. It's the
old
story "never assume".
Thanks for your help.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
Your problem was that, although you were 'disposing' the control, you
were
not removing it from tpMain's collection of controls. Therefore you end
up
with 'phantom' controls in tpMain's control collection.
Others might argue to the contrary, but I believe that the Dispose method
of
a CheckBox control does nothing special, and it certainly will not remove
itself from it's parent collection.
Therefore the code can be further simplified to:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
Next
To save you asking, the reverse loop is to ensure that iterating on the
control collection is still viable even when one or more of the iteration
actually removes an element.
"Siv" <Si*@discussions.microsoft.comwrote in message
news:3A**********************************@microsof t.com...
Stephany,
Thanks for your reply. Can you explain why the additional command
tpMain.Controls.RemoveAt(_i)
will do the trick where just doing the dispose on its own does not?
I appreciate you gave me the answer, but I try to learn from my
questions
here. Don't worry if you are too busy to reply, but if you do have time
I
would appreciate it.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
_ctrl.Dispose()
End If
Next
"Siv" <Si*@discussions.microsoft.comwrote in message
news:EC**********************************@microsof t.com...
I have a form that I programmatically generate some check boxes and
labels
on.
Later on when I want to draw the form with different data I want to
clear
the previously created items and then put some new ones on.
In my code I am doing the following:
For Each ctrl In tpMain.Controls
If TypeOf (ctrl) Is CheckBox Then
If ctrl.Name.StartsWith("chkS") Then
ctrl.Visible = False
ctrl.Dispose()
End If
End If
End if
Next
What I am finding however is that in some cases controls that I know
have
been affected by the above loop are staying on the form and not
being
made
invisible and then being disposed.
Is there a sure fire method of removing the controls rather than the
dispose
method which presumably is not always removing the control for
whatever
reason??
Siv
--
Martley, Near Worcester, UK
Jack,
Thanks for your response on this. My reason for using the dispose method
was just that. As this one tab page gets used all day by users clicking
items in a treeview to the left side of the form causing the application to
generate potentially 20 or 30 checkboxes relating to the data that the
selected item in the treeview represents. The user then interacts selecting
items using the checkboxes and then saves the results back to the database.
I then clear the check boxes I have dynamically created ready for the next
item that the user may select.
My biggest worry with this was that over a day's usage if I didn't dispose
of the controls, as you said, I would end up with the system's resources
being exhausted.
I am a VB developer since VB1 and I clearly remember this being an issue
particularly when running apps on Windows 3.1 which had a much smaller
resource stack than we have now under XP and you could quite easily exhaust
it. I remember apps that wold suddenly stop drawing parts of the screen
because the system had run out of memory to keep tabs on all the controls on
your form.
Happy days!
Siv
--
Martley, Near Worcester, UK
"Jack Jackson" wrote:
Cor,
I'm sure it is useless to argue with you, but it is misleading to say
that the purpose of Dispose is to tell the GC that the object " 'can
be' ready to clear up".
The purpose if Dispose is to release unmanaged resources. For
Controls, that would mostly be the Windows handle for the associated
Windows control. If you fail to call Dispose for a Control that has
allocated a Windows handle, then the handle might no be freed for a
very long time, and if you do this enough times you might run out of
Windows handles.
On Tue, 5 Aug 2008 06:47:35 +0200, "Cor Ligthert[MVP]"
<no************@planet.nlwrote:
Siv,
Disposing is not a removing method or whateverf, it is just telling the GC
that it "can be" ready to clear up, like the GC does that automaticly when
it is really needed. Dispose is meant to put it at the garbage. As anology,
some people are the whole day busy with cleaning up there desktop (putting
it in the trash bin, which still will not be direct emptied), others do that
once a day or/and some when that is needed.
As it is about forms, you can see in your designer part of the class
(versions before 2005 normal in the class) the implementing of IDisposable
of a form.
As long as an object is referenced by something (like on a form with
controls.add) it will not be cleared as long as that has a reference,
whatever other method you call (including dispose), mostly is that by clear
them all in one time or by removing them one by one.
Cor
"Siv" <Si*@discussions.microsoft.comschreef in bericht
news:EB**********************************@microsof t.com...
Stephany,
Thanks for clarifying, clearly I thought that to dispose of a control
would
by inference remove it from the tpMain collection of controls. It's the
old
story "never assume".
Thanks for your help.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
Your problem was that, although you were 'disposing' the control, you
were
not removing it from tpMain's collection of controls. Therefore you end
up
with 'phantom' controls in tpMain's control collection.
Others might argue to the contrary, but I believe that the Dispose method
of
a CheckBox control does nothing special, and it certainly will not remove
itself from it's parent collection.
Therefore the code can be further simplified to:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
Next
To save you asking, the reverse loop is to ensure that iterating on the
control collection is still viable even when one or more of the iteration
actually removes an element.
"Siv" <Si*@discussions.microsoft.comwrote in message
news:3A**********************************@microso ft.com...
Stephany,
Thanks for your reply. Can you explain why the additional command
tpMain.Controls.RemoveAt(_i)
will do the trick where just doing the dispose on its own does not?
I appreciate you gave me the answer, but I try to learn from my
questions
here. Don't worry if you are too busy to reply, but if you do have time
I
would appreciate it.
Siv
--
Martley, Near Worcester, UK
"Stephany Young" wrote:
For _i = tpMain.Controls.Count - 1 To 0 Step -1
Dim _ctrl = tpMain.Controls(_i)
If TypeOf (_ctrl) Is CheckBox AndAlso _ctrl.Name.StartsWith("chkS")
Then
tpMain.Controls.RemoveAt(_i)
_ctrl.Dispose()
End If
Next
"Siv" <Si*@discussions.microsoft.comwrote in message
news:EC**********************************@microso ft.com...
I have a form that I programmatically generate some check boxes and
labels
on.
Later on when I want to draw the form with different data I want to
clear
the previously created items and then put some new ones on.
In my code I am doing the following:
For Each ctrl In tpMain.Controls
If TypeOf (ctrl) Is CheckBox Then
If ctrl.Name.StartsWith("chkS") Then
ctrl.Visible = False
ctrl.Dispose()
End If
End If
End if
Next
What I am finding however is that in some cases controls that I know
have
been affected by the above loop are staying on the form and not
being
made
invisible and then being disposed.
Is there a sure fire method of removing the controls rather than the
dispose
method which presumably is not always removing the control for
whatever
reason??
Siv
--
Martley, Near Worcester, UK
On Wed, 6 Aug 2008 14:41:01 -0700, Siv <Si*@discussions.microsoft.com>
wrote:
>Jaxk,
Sounds complicated. I assume that just not disposing the datareader means
it will be disposed by the GAC whenever there is nothing referencing it some
time down the line. I just have a problem with not being able to tidy things
up there and then. I don't like loose ends.
Siv
The caller should dispose of it. Once your method returns a reference
to the DataReader, ownership of the DataReader should pass to the
caller and the caller becomes responsible for disposing of it.
This isn't any different from your program allocating a GDI object.
Once the object is returned to your program, it becomes your program's
responsibility to dispose it once it is no longer needed.
Whenever you use an object that needs to be disposed, you need to
maintain the concept of ownership - something must be in charge of
knowing when the object is no longer needed and disposing of it.
On Wed, 6 Aug 2008 14:55:01 -0700, Siv <Si*@discussions.microsoft.com>
wrote:
>Cor,
That really was the answer to my question. That is, I don't need to
implicitly dispose of the Datareader (doing so would stop the function doing
its job anyway) if I can be sure that ultimately the Datareader will be
destroyed when it is no longer referenced I am fine with that. I just don't
want my apps slowly consuming more and more resources as they run and this
was my worry with leaving objects un disposed.
Siv
This is where Cor and a number of others here disagree. I believe
Cor's opinion is that since the DataReader doesn't do anything useful
in its Dispose method, that there is no reason to call it.
My belief is that if there is a Dispose method it should be called.
First, I don't want to take the time to investigate every object with
a Dispose method to see if that method really does anything. Second,
I don't want to have to remember to make that same investigation for
every new version of the .NET libraries in case at some time in the
future an object starts doing something useful in its Dispose.
Jack (and siv),
You did not read my message, in the case of the datareader I wrote that the
close should be called, which does explititly the same as the dispose, that
instead of that using" could be used or because it exlicitly the same as the
close the dispose could be called instead of the close. Those methods in
the datareader dispose releases the connection. However it would not be
needed for the datareader itself as it had no unmanaged resources.
I don't want to have to remember to make that same investigation for
every new version of the .NET libraries in case at some time in the
future an object starts doing something useful in its Dispose.
As it is about this one, you can not even rely on the working of the + and
the -. This is something Microsoft development team careful tries to control
that it does not happen. The DBDataReader.Dispose will stay the same as now
(or somebody should make a very big mistake as every developer can do). That
does not mean that the WhatEverNew.dispose can have extras we don't know
yet, but that can even be something as create a new object or to close your
program.
Don't forget that Microsoft changed in the beginning of Microsoft the name
Mail Server in Exchange, while that was already the name of the mailclient
(curently Outlook). Therefore the change that what you write will happen
agains is low.
Cor
"Jack Jackson" <jj******@cinnovations.netschreef in bericht
news:fc********************************@4ax.com...
On Wed, 6 Aug 2008 14:55:01 -0700, Siv <Si*@discussions.microsoft.com>
wrote:
>>Cor,
That really was the answer to my question. That is, I don't need to
implicitly dispose of the Datareader (doing so would stop the function
doing
its job anyway) if I can be sure that ultimately the Datareader will be
destroyed when it is no longer referenced I am fine with that. I just
don't
want my apps slowly consuming more and more resources as they run and this
was my worry with leaving objects un disposed.
Siv
This is where Cor and a number of others here disagree. I believe
Cor's opinion is that since the DataReader doesn't do anything useful
in its Dispose method, that there is no reason to call it.
My belief is that if there is a Dispose method it should be called.
First, I don't want to take the time to investigate every object with
a Dispose method to see if that method really does anything. Second,
I don't want to have to remember to make that same investigation for
every new version of the .NET libraries in case at some time in the
future an object starts doing something useful in its Dispose.
Jack,
I am pleased to report that in pretty much ebery instance the calling
routine will have something like this:
Dim CallersDR as sqlDataReader=nothing
try
CallersDR = GetData(SomeID)
...
various code that uses the CallersDR.
...
Catch ex as exception
Error handler code
Finally
if not isnothing(CallersDR) then
CallersDR.Close()
End If
End Try
So if I read teh conversations correctly, the line:
CallersDR.Close()
Will not only close the CallersDR but will also close the Dr that is in the
black box routine (GetData(ID)) as well? This is the concept that I didn't
follow and what was worrying me because in my mind I see the Dr used in the
GetData as being a separate object to the one in the above calling routine.
So therefore I have been worrying that this was being left undisposed.
Am I right in surmising from what has been said above that the Dr in GetData
and teh CallersDR in my calling routine are both referencing the same
DataReader object from the moment that the GetData routine returns the Dr it
has to the caller??
If this is correct I will be a happy man as this has clarified something I
have not understood properly.
Siv
--
Martley, Near Worcester, UK
"Jack Jackson" wrote:
On Wed, 6 Aug 2008 14:41:01 -0700, Siv <Si*@discussions.microsoft.com>
wrote:
Jaxk,
Sounds complicated. I assume that just not disposing the datareader means
it will be disposed by the GAC whenever there is nothing referencing it some
time down the line. I just have a problem with not being able to tidy things
up there and then. I don't like loose ends.
Siv
The caller should dispose of it. Once your method returns a reference
to the DataReader, ownership of the DataReader should pass to the
caller and the caller becomes responsible for disposing of it.
This isn't any different from your program allocating a GDI object.
Once the object is returned to your program, it becomes your program's
responsibility to dispose it once it is no longer needed.
Whenever you use an object that needs to be disposed, you need to
maintain the concept of ownership - something must be in charge of
knowing when the object is no longer needed and disposing of it.
On Thu, 7 Aug 2008 12:52:01 -0700, Siv <Si*@discussions.microsoft.com>
wrote:
>Jack,
I am pleased to report that in pretty much ebery instance the calling
routine will have something like this:
Dim CallersDR as sqlDataReader=nothing
try
CallersDR = GetData(SomeID)
...
various code that uses the CallersDR.
...
Catch ex as exception
Error handler code
Finally
if not isnothing(CallersDR) then
CallersDR.Close()
End If
End Try
So if I read teh conversations correctly, the line:
CallersDR.Close()
Will not only close the CallersDR but will also close the Dr that is in the
black box routine (GetData(ID)) as well? This is the concept that I didn't
follow and what was worrying me because in my mind I see the Dr used in the
GetData as being a separate object to the one in the above calling routine.
So therefore I have been worrying that this was being left undisposed.
Am I right in surmising from what has been said above that the Dr in GetData
and teh CallersDR in my calling routine are both referencing the same
DataReader object from the moment that the GetData routine returns the Dr it
has to the caller??
If this is correct I will be a happy man as this has clarified something I
have not understood properly.
Siv
There is no "Dr that is in the black box routine (GetData(ID)) as
well". There is only one SqlDataReader. The black box method creates
it and returns a reference to it. The reference that the black box
method holds to the object goes away once the method exits, leaving
only the caller's reference.
It's like this:
Dim dr As New SqlDataReader
Dim dr1 As SqlDataReader = dr
Dim dr2 As SqlDataReader = dr
There is only one object with three references to that object: dr, dr1
and dr2.
Jack,
This is where my VB6 roots probably show. I always treat = (equals) as
meaning copy from the right side to the left side. From what you have just
said that isn't the case, in this instance I am making my variable on the
left side actually equal to rather than assigning.
Now I understand that, I can see that if I dispose (or destruct if you
believe what Cor says), the variable on the left side of the argument, I am
also disposing the original one as they are one and the same object.
That actually makes me a lot happier. Also knowing that as soon as I exit
the black box function that reference is removed helps. I feel a lot tidier
knowing that.
Thanks for you help.
Siv
--
Martley, Near Worcester, UK
"Jack Jackson" wrote:
On Thu, 7 Aug 2008 12:52:01 -0700, Siv <Si*@discussions.microsoft.com>
wrote:
Jack,
I am pleased to report that in pretty much ebery instance the calling
routine will have something like this:
Dim CallersDR as sqlDataReader=nothing
try
CallersDR = GetData(SomeID)
...
various code that uses the CallersDR.
...
Catch ex as exception
Error handler code
Finally
if not isnothing(CallersDR) then
CallersDR.Close()
End If
End Try
So if I read teh conversations correctly, the line:
CallersDR.Close()
Will not only close the CallersDR but will also close the Dr that is in the
black box routine (GetData(ID)) as well? This is the concept that I didn't
follow and what was worrying me because in my mind I see the Dr used in the
GetData as being a separate object to the one in the above calling routine.
So therefore I have been worrying that this was being left undisposed.
Am I right in surmising from what has been said above that the Dr in GetData
and teh CallersDR in my calling routine are both referencing the same
DataReader object from the moment that the GetData routine returns the Dr it
has to the caller??
If this is correct I will be a happy man as this has clarified something I
have not understood properly.
Siv
There is no "Dr that is in the black box routine (GetData(ID)) as
well". There is only one SqlDataReader. The black box method creates
it and returns a reference to it. The reference that the black box
method holds to the object goes away once the method exits, leaving
only the caller's reference.
It's like this:
Dim dr As New SqlDataReader
Dim dr1 As SqlDataReader = dr
Dim dr2 As SqlDataReader = dr
There is only one object with three references to that object: dr, dr1
and dr2.
On Sun, 10 Aug 2008 10:44:00 -0700, Siv
<Si*@discussions.microsoft.comwrote:
>Jack,
This is where my VB6 roots probably show. I always treat = (equals) as
meaning copy from the right side to the left side. From what you have just
said that isn't the case, in this instance I am making my variable on the
left side actually equal to rather than assigning.
Now I understand that, I can see that if I dispose (or destruct if you
believe what Cor says), the variable on the left side of the argument, I am
also disposing the original one as they are one and the same object.
That actually makes me a lot happier. Also knowing that as soon as I exit
the black box function that reference is removed helps. I feel a lot tidier
knowing that.
Thanks for you help.
Siv
= does mean copy from the right side to the left. The problem is
determining what is being copied.
..NET has two types of objects, Value and Reference.
Value objects (Integer, DateTime, etc.) are copied.
With Reference objects, references (like pointers in C) are used - the
= operator sets the variable on the left side to be a reference to the
same object as the item on the right. When x and y are references and
you say "x = y" you are copying the value of y to x, but the 'value'
in this case is a reference to an object, not an object.
It is not correct to say that you "dispose the variable on the left
side ...". When you say "x.Dispose()", you are calling the Dispose
method of the object references by the variable x. The object is
being disposed, not the variable.
Jack,
Thanks again, you have just moved my knowledge up another notch.
Is there an easy way to find out whether an object is a "Value" object or a
"Reference" object, as now I understand the difference, I want to be sure
that I deal with my variables properly.
Siv
--
Martley, Near Worcester, UK
"Jack Jackson" wrote:
On Sun, 10 Aug 2008 10:44:00 -0700, Siv
<Si*@discussions.microsoft.comwrote:
Jack,
This is where my VB6 roots probably show. I always treat = (equals) as
meaning copy from the right side to the left side. From what you have just
said that isn't the case, in this instance I am making my variable on the
left side actually equal to rather than assigning.
Now I understand that, I can see that if I dispose (or destruct if you
believe what Cor says), the variable on the left side of the argument, I am
also disposing the original one as they are one and the same object.
That actually makes me a lot happier. Also knowing that as soon as I exit
the black box function that reference is removed helps. I feel a lot tidier
knowing that.
Thanks for you help.
Siv
= does mean copy from the right side to the left. The problem is
determining what is being copied.
..NET has two types of objects, Value and Reference.
Value objects (Integer, DateTime, etc.) are copied.
With Reference objects, references (like pointers in C) are used - the
= operator sets the variable on the left side to be a reference to the
same object as the item on the right. When x and y are references and
you say "x = y" you are copying the value of y to x, but the 'value'
in this case is a reference to an object, not an object.
It is not correct to say that you "dispose the variable on the left
side ...". When you say "x.Dispose()", you are calling the Dispose
method of the object references by the variable x. The object is
being disposed, not the variable.
Jack,
I followed the link in one of Cor's posts and it was some stuff in the MSDN
site that discussed disposal of objects. On reading that and then follwoing
some other links I got the impresion that including a dispose method in your
class modules actually was not needed unless you had some unmanaged resources
to dispose of. In fact I get the impression that including a dispose method
actually slowed things down if there were no unmanaged resources?
Have I understood that correctly? Also, what are some examples of unmanaged
resources, I am again not sure how you identify those?
Siv
--
Martley, Near Worcester, UK
"Jack Jackson" wrote:
On Sun, 10 Aug 2008 10:44:00 -0700, Siv
<Si*@discussions.microsoft.comwrote:
Jack,
This is where my VB6 roots probably show. I always treat = (equals) as
meaning copy from the right side to the left side. From what you have just
said that isn't the case, in this instance I am making my variable on the
left side actually equal to rather than assigning.
Now I understand that, I can see that if I dispose (or destruct if you
believe what Cor says), the variable on the left side of the argument, I am
also disposing the original one as they are one and the same object.
That actually makes me a lot happier. Also knowing that as soon as I exit
the black box function that reference is removed helps. I feel a lot tidier
knowing that.
Thanks for you help.
Siv
= does mean copy from the right side to the left. The problem is
determining what is being copied.
..NET has two types of objects, Value and Reference.
Value objects (Integer, DateTime, etc.) are copied.
With Reference objects, references (like pointers in C) are used - the
= operator sets the variable on the left side to be a reference to the
same object as the item on the right. When x and y are references and
you say "x = y" you are copying the value of y to x, but the 'value'
in this case is a reference to an object, not an object.
It is not correct to say that you "dispose the variable on the left
side ...". When you say "x.Dispose()", you are calling the Dispose
method of the object references by the variable x. The object is
being disposed, not the variable.
On Mon, 11 Aug 2008 01:55:18 -0700, Siv
<Si*@discussions.microsoft.comwrote:
>Jack,
Thanks again, you have just moved my knowledge up another notch.
Is there an easy way to find out whether an object is a "Value" object or a
"Reference" object, as now I understand the difference, I want to be sure
that I deal with my variables properly.
Siv
Look at the documentation. For example DateTime
(<http://msdn.microsoft.com/en-us/library/system.datetime.aspx>),
under Remarks it says "value type".
Another clue is that usually value items with multiple properties
don't allow you to change any of the properties - a new object must be
created instead.
On Mon, 11 Aug 2008 02:03:11 -0700, Siv
<Si*@discussions.microsoft.comwrote:
>Jack,
I followed the link in one of Cor's posts and it was some stuff in the MSDN
site that discussed disposal of objects. On reading that and then follwoing
some other links I got the impresion that including a dispose method in your
class modules actually was not needed unless you had some unmanaged resources
to dispose of. In fact I get the impression that including a dispose method
actually slowed things down if there were no unmanaged resources?
Have I understood that correctly? Also, what are some examples of unmanaged
resources, I am again not sure how you identify those?
Siv
Unmanaged resources are things like Windows handles (file handles, GDI
handles, etc.) - things that don't come from .NET.
Having Dispose does not slow anything down. Having a Finalizer does.
An object that implements Dispose often also implements a Finalizer. A
Finalizer is code that runs when the garbage collector frees the
object to take care of the case where the programmer did not call
Dispose - it effectively disposes the object at garbage collection
time.
For objects that have a Finalizer, the usual sequence is that the
programmer calls Dispose, which frees the unmanaged resources and (if
the object is coded correctly) tells the garbage collector that the
Finalizer does not have to be called. Should the programmer fail to
call Dispose, then the garbage collector will call the Finalizer
before releasing the object, which will then release the unmanaged
resources.
If the garbage collector has to call the Finalizer, that causes a
performance problem.
The bottom line is that if an object has a Finalizer and its Dispose
is not called, there will be a perfornamce impact. There are two
important reasons to call Dispose for objects that have a Finalizer.
First, to free unmanaged resources in a timely manner, and second to
prevent extra work for the garbage collector.
There are a couple of good articles on the garbage collector here:
# Jeffery Richter. Garbage Collection: Automatic Memory Management in
the Microsoft .NET Framework". MSDN Magazine, November 2000.
<http://msdn.microsoft.com/msdnmag/issues/1100/GCI/>
# Jeffery Richter. Garbage Collection - Part 2: Automatic Memory
Management in the Microsoft .NET Framework". MSDN Magazine, December
2000.
<http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/>
Jack,
Thanks for pointing that out. It is not hugely obvious until you know the
meaning of that term. I would have expected a heading saying
Value or Reference Type: Value
or something similar near the top of the description of the object.
Thanks,
Siv
--
Martley, Near Worcester, UK
"Jack Jackson" wrote:
On Mon, 11 Aug 2008 01:55:18 -0700, Siv
<Si*@discussions.microsoft.comwrote:
Jack,
Thanks again, you have just moved my knowledge up another notch.
Is there an easy way to find out whether an object is a "Value" object or a
"Reference" object, as now I understand the difference, I want to be sure
that I deal with my variables properly.
Siv
Look at the documentation. For example DateTime
(<http://msdn.microsoft.com/en-us/library/system.datetime.aspx>),
under Remarks it says "value type".
Another clue is that usually value items with multiple properties
don't allow you to change any of the properties - a new object must be
created instead.
Jack,
Thanks for the links, this is an area that I want to be on the ball with.
When I made the jump from VB6 to VB.NET 2003, I bought a couple of Dot Net
books and worked through them and can't say that they covered this topic well
for someone who was migrating from VB6 to Dot Net.
The first was "SAMS teach Yourself Microsoft Visual Basic .NET 2003 in 24
hours" and at the other end of the complexity spectrum was; "Moving to VB.NET
Strategies Concepts and Code" by Dan Appleman. The former was good at
getting you up and running and the latter was a more detailed look. Dan's
book covered disposal, but my experience with .NET programming at the time
meant that I didn't fully appreciate what was being said.
With your help here and all the intervening time I will re-read Dan
Appleman's book and the links you highlighted at the end of that I should not
be making any stupid mistakes with disposal and creation of objects.
Thanks again for all your time guiding me through this it is much
appreciated.
Are you a VB.NET tutor or writer as you knowledge seems pretty extensive on
these subjects??
Siv
--
Martley, Near Worcester, UK
"Jack Jackson" wrote:
On Mon, 11 Aug 2008 02:03:11 -0700, Siv
<Si*@discussions.microsoft.comwrote:
Jack,
I followed the link in one of Cor's posts and it was some stuff in the MSDN
site that discussed disposal of objects. On reading that and then follwoing
some other links I got the impresion that including a dispose method in your
class modules actually was not needed unless you had some unmanaged resources
to dispose of. In fact I get the impression that including a dispose method
actually slowed things down if there were no unmanaged resources?
Have I understood that correctly? Also, what are some examples of unmanaged
resources, I am again not sure how you identify those?
Siv
Unmanaged resources are things like Windows handles (file handles, GDI
handles, etc.) - things that don't come from .NET.
Having Dispose does not slow anything down. Having a Finalizer does.
An object that implements Dispose often also implements a Finalizer. A
Finalizer is code that runs when the garbage collector frees the
object to take care of the case where the programmer did not call
Dispose - it effectively disposes the object at garbage collection
time.
For objects that have a Finalizer, the usual sequence is that the
programmer calls Dispose, which frees the unmanaged resources and (if
the object is coded correctly) tells the garbage collector that the
Finalizer does not have to be called. Should the programmer fail to
call Dispose, then the garbage collector will call the Finalizer
before releasing the object, which will then release the unmanaged
resources.
If the garbage collector has to call the Finalizer, that causes a
performance problem.
The bottom line is that if an object has a Finalizer and its Dispose
is not called, there will be a perfornamce impact. There are two
important reasons to call Dispose for objects that have a Finalizer.
First, to free unmanaged resources in a timely manner, and second to
prevent extra work for the garbage collector.
There are a couple of good articles on the garbage collector here:
# Jeffery Richter. Garbage Collection: Automatic Memory Management in
the Microsoft .NET Framework". MSDN Magazine, November 2000.
<http://msdn.microsoft.com/msdnmag/issues/1100/GCI/>
# Jeffery Richter. Garbage Collection - Part 2: Automatic Memory
Management in the Microsoft .NET Framework". MSDN Magazine, December
2000.
<http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/>
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Jim Mitchell |
last post by:
I have some code behind that generates 10 imagebutton controls.... I can
not seem to figure out how to trap the onclick event for each image and
determine which image was clicked.
Can someone...
|
by: Joe |
last post by:
I'm wondering how to loop through controls in VB.NET. I have the code from VB6 ok, but I can't figure out how to do it correctly in .NET. This is an example from my VB6 code that loops through...
|
by: TD |
last post by:
This is the code under a command button -
Dim ctl As Control
For Each ctl In Me.Controls
If ctl.BackColor <> RGB(255, 255, 255) Then
ctl.BackColor = RGB(255, 255, 255)
End If
Next ctl
|
by: Rachel Suddeth |
last post by:
Here is my scenario:
I have a few custom controls that I set up on a form and tested setting
properties and appearances.
Then I added a couple references to the project which add classes I need to...
|
by: StriderBob |
last post by:
Situation :
FormX is mdi child form containing 2 ListViews
ListView1 contains a list of table names and 4 sub items with data about
each table.
ListView2 contains a list of the columns on each...
| | |
by: Eduardo78 |
last post by:
Hello everybody,
I heard I could clear (or move spaces) to all controls at ones without
having to call each one of them. If someone remembers how to do that, I will
apreciate your help.
My...
|
by: RP |
last post by:
I want to clear all the Text Boxes on the Form. Is there any short
method to avoid clearing them one by one.
|
by: karsagarwal |
last post by:
I have a bounded form and after I click the button to update/save. THe
fields are still there. Is there a way to clear off the fields in the
bounded form.
Thanks,
SA
Here's the code that I...
|
by: aas4mis |
last post by:
I haven't had much luck with specific controls, their properties and loops in the past. I thought I would share this tidbit of code, feel free to modify/modularize in any way to suit your needs. This...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
