If I close a form in vb.net by using .dispose(), do I need to worry about cleaning up any of the elements that were created inside the form (like addHandler, etc) or does disposal clean up everything for me?
Thanks.
Closing a Form (or calling Dispose() on it) will clean up all of the components within that form. This means that any controls added to the form (or its controls, recursively) will automatically clean up.
Event handlers on controls within the form will get cleaned up.
That being said, this will not clean up event handlers which are subscribing to objects not owned by the form. If you used AddHandler to add an event handler to a type outside of the form, it would be a good practice to use RemoveHandler within an override of Form.Dispose(Boolean) to remove this subscription.
Related
A older application loads some forms using implicit instances:
form2.showdialog()
Sometime between VS2008 32-bit and VS2013 64-bit, the forms stopped being initialized when they are reloaded. For example, if you load a form, close the form (using the Close method), and load the form again, the classes and controls (and, I assume, the form) are not initialized as new instances.
Re-initialization can be accomplished by putting me.dispose() in the FormClosed event, or by using an explicit instance of the form:
Using frm As New Form2
frm.ShowDialog()
End Using
Is there a good reason to use one of these methods over the other, or is there another method that should be used to cause a form to be initialized when it is reloaded?
Dispose will be called automatically if the form is shown using the Show method. If another method such as ShowDialog is used (your case it is), or the form is never shown at all, you must call Dispose yourself within your application. You can also handle the dispose by moving it from the designer file into the code file and handle things there as well.
On the other hand, Using statement typically makes your application safer to maintain and less prone to deadlocks and other misbehavior related to the lifecycle of the resource. I would stick by using this approach.
Also you cant put Me.Dispose in the Form Closed event (possible issues). If your using ShowDialog it will fail as it will dispose your objects first, if you need them they are gone.
Here's more on dispose: https://msdn.microsoft.com/en-us/library/aw58wzka(v=vs.110).aspx
The Form object and its child controls are not automatically disposed when you display the form with ShowDialog(). That sounds pretty quirky but this was done for a very good reason. After ShowDialog returns DialogResult.OK, you are normally going to obtain the dialog results. What nobody likes is that failing because of a ObjectDisposedException. Which would be likely to occur since the dialog results are often stored in controls.
You should always use the Using statement to ensure the form object and all of its controls are disposed.
A possible corner case is intentionally not disposing it because you like the redisplay the dialog with the original entered values. Which is not completely wrong, it is however a very expensive way to preserve those values. Those undisposed window objects cost an arm and a leg in system resources.
Pretty clear explanation from MSDN
Unlike non-modal forms, the Close method is not called by the .NET
Framework when the user clicks the close form button of a dialog box
or sets the value of the DialogResult property. Instead the form is
hidden and can be shown again without creating a new instance of the
dialog box. Because a form displayed as a dialog box is hidden instead
of closed, you must call the Dispose method of the form when the form
is no longer needed by your application.
When ShowDialog() called and closed, instance of the form will remain in the memory, and can be used again, for example get a result from some public property.
If you not using anymore this form, you need to call Dispose method to dispose form and form's controls
Dim myform As New MyDialogForm()
myform.ShowDialog()
Dim result As Object = myForm.SelectedResult()
myform.Dispose() 'need to call manually, if instance not used anymore
When you use Using keyword then Dispose method will be executed automatically at the end of the Using block
Dim result As Object
Using myform As New MyDialogForm()
myform.ShowDialog()
result = myForm.SelectedResult()
End Using 'myform.Dispose will be called
Bottom line: Both methods doing a same things.
But Using block will call Dispose method automatically
P.S. Putting Me.Dispose in the FormClosed eventhandler then
- instance of the form will stay in the memory even form was closed
- and will work only until you tried using disposed controls again. If you will try to show disposed object then ObjectDisposedException will be thrown.
If you not using form anymore then Using block will be best method
I'm working in a windows application. using VB.NET 1.1
I have an empty form, and I want to generate my design in load session (not in form_load event! but in my form's constructor)
So I know I must generate my components in constructor, but I don't know how to generate button events. I mean I haven't any button in design mode, and these are generating in run-time mode. so how I set button events in this session?
And if you have a better solution for run-time design generation, give it to me. thanks ;)
A few things.
You may add controls at practically any point. It can be in the constructor, the Load, in response to another event, or when a custom method is called.
You can wire up events by using AddHandler myButton.Click, AddressOf Button_Click. You'll have to define the Button_Click event handlder and it will need to have the appropriate signature, which for a button click is (sender as object, e as EventArgs).
When in doubt, temporarily add a real control to you form and go to the hidden designer code (MyForm.vDesigner.vb) and see what is generated as a sample. Copy that code and move it into the main populating code. Then delete the control.
Good luck!
I have a Windows Form that contains a custom control container as a UserControl. For the sake of this question, this custom control container is called Dashboard. This container called Dashboard contains numerous other controls depending on their permissions. I need to raise events that are contained on these controls through the Dashboard control and over to the Windows Form.
How can I bubble up the event? I'm using VB.NET for this project, but can convert C# into VB.NET.
Also, to complicate matters, the main Windows Form is a VB6 project. So, I'm using the InteropFormsToolkit to accomplish this.
I figured it out. I just did what I had said that I wanted to do and created an event with a custom eventargs class and bubbled it up to the VB6 app. Each control needed to implement the custom event such as:
Public Event OnMyCustomEvent(source As Object, e As MyCustomEventArgs)
And continue raising that event up to VB6. In VB6 that event was exposed as a function for me to handle as necessary.
I ma using DevExpress controls (which doesnt matter for this example). I have a lookupEdit control and I never want the EditValue_Changed event to fire. Can I use RemoveHandler to do this? If so can someone give me a code example of doing this? Should I put RemoveHandler in the load event of the user control I am creating? Or does it go in the EditValue_Changed event of the lookupControl?
THIS IS A WINDOWS APP NO POSTBACK....Sorry
You can use RemoveHandler from any event you add to an object within one of your own classes. If the event is defined and being handled within a class you do not have access to, you will not be able to remove its handler events.
It would be instructive to learn where this EditValue_Changed event is firing. If it is firing within your application, then you must have wired it up either in the designer or in the code (which means you should be able to call RemoveHandler without difficulty). If this belongs to a 3rd party library and is auto-configured, you may not have this access.
You can't stop the control from firing the postback, but you can just not wire up an event handler to a control's event. You don't need RemoveHandler to do that; just don't attach to the event... But it seem like the issue is the postback, DevExpress should have a feature in there to fire a client-side event, and keep that all on the client and not have to worry about a server-side postback.
If this doesn't help, could you explain more about the problem?
HTH.
You might be able to subclass the control and override the method(s) that trigger the EditValue_Changed event to fire. If you have access to the source code, find where its being called and if that code can be overridden.
I have a windows form in .NET that will serve as a wizard to achieve something. This contains 3 steps: Step1, Step2, Step3.
Each step is again actually a user control. Main form contains a panel that display the current Step. When I change among steps then:
1) Dispose the current user control by calling its Dispose() method.
2) Clears the main form panel
3) Initialize the user control of next step and add it into the main panel
Now, the issue is, User control of step one contains one more user control. When I change to another step and come back to step 1, I get following error:
"Cannot access disposed object."
Because I have to first dispose the user control before actually displaying the another step. And when I come back to step 1 and tries to open the user control on step 1, it gives the aforementioned error.
Everything in the Controls collection of a Control is disposed when the control is disposed. So if you need to reuse those user controls, you'll need to remove them from the parent user control before disposing it.
You don't actually have to dispose the user control before displaying the next one. You can just remove it from the main form and put the new one on the main form when the step changes. Keep your user controls in a list or a dictionary and dispose them all when the main form is closing.
Why do you need to dispose the user control? Typically, when the form closes, it will dispose of all of it's child controls for you.
When you call dispose on an object, you are essentially telling it to go away.. you don't want it anymore. You can't change your mind -- once it's disposed, it's gone. Don't try to use it anymore.
Typically, you don't call dispose on an object directly; you should use the "using" pattern to avoid disposing of an object before you need it again, and to ensure the object is disposed once you are done with it.