Using the AddHandler method, if I never use RemoveHandler, will that lead to memory leaks in some conditions and situations? I'm not so sure about the truth of this.
And are there other causes to memory leaks that are solely available in VB as opposed to C#?
Well usually it doesn't.. but the possibility exists.
When you subscribe to an event, you basically give a delegate (a func pointer if you will) to your method to the event publisher, who holds on to it as long as you do not unsubscribe with the -= operator.
So take for example, the case where you spawn a child form and the form subscribes to the Click button event on the form.
button1.Click += new EventHandler(Form_Click_Handler);
Now the button object will hold on to the form reference.. When the form is closed/disposed/set to null both form and button are not needed anymore; memory is reclaimed.
The trouble happens when you have a global structure or object which has a bigger lifetime. Lets say the Application object maintains a list of open child windows. So whenever a child form is created, the application object subscribes to a Form event so that it can keep tabs on it. In this case, even when the form is closed/disposed the application object keeps it alive (a non-garbage object holds a ref to the form) and doesn't allow its memory to be reclaimed. As you keep creating and closing windows, you have a leak with your app hogging more and more memory. Hence you need to explicitly unsubscribe to remove the form reference from the application.
childForm.Event -= new EventHandler(Form_Handler)
So its recommended that you have a unsubscribe block (-=) complementing your subscribe routine (+=)... however you could manage without it for the stock scenarios.
If object a is suscribed to the object b event then object b will not be collected until object a is collected.
An event suscription counts as a reference to the publisher object.
And yes, this happens on C# too, i has nothing to do with the language.
Related
This issue affects both my VB.NET and C# Winform applications. When closing Form containing Adobe PDF Viewer conreol, the Form takex some 10 seconds to close. I tracked the issue down to Dispose method. Normally, in C# all it takes it so steal focus from Adobe PDF Control by adding lines to FormClosing event handler but in VB.NET, even if I steal focus, it still takes way too long for the Form to close. I tried to explicitly dispose the control and Implicitly - by disposing the containing Form. I tried empty string in LoadFile() method. I tried new reference to new interop library. Nothing works.
Also, if you would suggest a different API/library to replace AxAcroPDFlib I'd love to read what you use.
I now have a solution. Early testing is promising.
In short, add Controls.Remove(yourPdfViewerControl) to FormClosing event handler. Of course this will offer instant alleviation of the problem but may cause memory leak. After you have removed the control from Container you could assugn null to its memory address and hope that memory manager will do its job. So in order to prevent the leak, I created a class holding one memory space for PdfViewer control. If a Form needs a viewer, it requests it from an object that is accessible from any form to prevent memory leaks. To avoid Dispose method invocation when Form closes, make sure you remove this Control from Controls container.
I can provide sample code if needed.
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 have a UI element in my application where a Panel is used to host one of several potential custom UserControls. The Panel itself is hosted in a standardised UserControl that I am using something like a non-modal dialog that I'm calling a 'pane'.
The method I use is to instantiate a new instance of the standard pane, then with logic instantiate one of the several optional hosted controls inside it using Panel.Controls.Add(control). I then add the new pane to the interface control in a set location, again with a Control.Controls.Add(control), followed by a control.BringToFront() to maximise its z position.
This all works well, however when the time comes to hide the pane and destroy it, I cannot seem to fully get rid of it. Originally I was simply using Control.Controls.Remove(control) and for good measure setting the pane's Parent property to Nothing. This would have the desired effect of making the pane disappear, and my assumption was that now the control was unreferenced, that GC would dispose of it.
What I am seeing however is that the control still blits instantaneously onto the screen when the next outer hosting TabControl changes tab page, implying it still exists somewhere. I can confirm that this is not a graphical issue and the pane object persists using the VS Watch window's 'Make Object ID'. (At least I think this is proof, that without a code-accessible reference I can still directly see the object and its properties continue to exist.)
I have tried replacing
Control.Controls.Remove(pane)
pane.Parent = Nothing
with
pane.Dispose()
GC.Collect()
where the Dispose call I can confirm both removes the control from its parent's Controls collection and sets its Parent property to Nothing, but appears to do no more. It persists after forced GC and still blits onscreen occasionally.
This all leads to my original question, what is the proper way to remove and fully destroy controls after they have served their purpose?
According to this article from MSDN it seems like you might be experiencing side affects from the object being on the finalization queue.
A Dispose method should call the GC.SuppressFinalize method for the object it is disposing. If the object is currently on the finalization queue, GC.SuppressFinalize prevents its Finalize method from being called.
Translation: The finalize method isn't being called, and so the resources associated with your control are not being released. After a bit more digging, I found that you should
Always call Dispose before you release your last reference to the Component. Otherwise, the resources it is using will not be freed until the garbage collector calls the Component object's Finalize method.
From this article.
So either you need to release your last reference OR you need to call the components finalize method directly so your GC.Collect() will work.
I have a series of methods being called for my networking code. An event gets fired from the networking thread. Inside this event, which I've hooked into from a singleton class, I route messages to form level methods which they register on form load to handle certain messages they care about. Inside of these form message hooks I need to close the current form (which I was able to do) but also show a different one (which is giving me the trouble).
The new form sort of shows but it's hanging/not updating. I'm sure this has something to do with that form because it's .Show() was basically called from another thread (sort of) doesn't have a message loop, but I'm not sure how else to solve this. The network message that gets received indicates on the client machine what forms to close and show.
The flow might be confusing so I'll try better to explain.
Login form attaches user defined functions inside that form to a singleton class list of messages. For example when a message called LOGIN_STATUS is fired I assign a function from the Login form to a list defined in this singleton class.
The singleton class has the network class defined in it which actually runs on another thread, but this is all handled inside the class. In the private ctor I subscribe to the OnData event of this network class.
When OnData gets fired from the network class to the singleton class it passes to it the type of data. I loop through the list of function pointers to see if any of them are linked to LOGIN_STATUS and if so call them. This will call the Login forms function. Inside that function I need to close the Login form and open the Lobby form. That's when the Lobby form shows, but is hung up and not updating.
Hope that makes sense.
This is all being done in VB.NET where I have the "close when last form closed" setting on which is what I want. VB.NET also makes it easier to manage forms since I can just for formname.Show() instead of having to keep a list of the forms and manage them myself like in C# so if that's still possible with the solution that would be ideal.
If you want to ensure all forms are created on the same thread, and hence the same message loop, use the main from's Invoke method. The Form.Invoke and Form.BeginInvoke methods cause the code to run from the form's message loop. BeginInvoke allows the event calling thread to return immediately, where-as Invoke blocks the event thread until the method is complete. It depends how time sensitive your code is.
Private Sub OpenFormEvent(sender As Object, e As EventArgs)
If MainForm.InvokeRequired Then
Dim args As Object() = {sender, e}
MainForm.BeginInvoke(New EventHandler(AddressOf OpenFormEvent), args)
Else
Dim SecondForm As New Form()
SecondForm.Show()
End If
End Sub
I'm trying to figure out the lifetime of the tmpTabPages in the following bit of code. Lets assume the form has an empty TabControl named MyTabControl, that there's a collection of strings called NameCollection.
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
For Each itm In NameCollection
Dim tmpTabPage as New TabPage(itm.toString)
'Add Controls to tmpTabPage
MyTabControl.TabPages.Add(tmpTabPage)
Next
End Sub
Since the scope of the tmpTabPage is the For/Next block, typically it's lifetime would be until the end of the block right? But since it is added to a collection that has a scope outside of the block does it get the same lifetime as the collection, or in this case the MyTabControl? Finally, if I call MyTabControl.TabPages.Clear will the tmpTabPages in the collection be destroyed or will they just sit around taking up memory?
The big deal about classes derived from Control (including TabPage) is the Dispose() method. They are immune from automatic garbage collection, Winforms keeps an internal table that maps the Handle of a control to the control reference. That's why, say, your main form doesn't suddenly get garbage collected, even though your program doesn't keep a reference to it.
Adding the TabPage to the TabControl's collection takes care of automatic disposal. The same applies for the TabControl, it would be added to the form's Controls collection. The normal chain of events is that either your program or the user closes the form. The Form class iterates its child controls and calls their Dispose() method. TabControl does the same thing in its Dispose() method, disposing the tab pages. The Windows window gets destroyed in the process, removing the Handle from that mapping table and now allowing the garbage collector to, eventually, collect the managed wrapper for the controls.
There is a nasty trap that gets many Winforms programmers in trouble. If you remove a control from its parent's collection then you get the responsibility of disposing it yourself. Removing it does not automatically dispose it. Winforms keeps the native window alive by temporarily re-parenting the control to a hidden window named the "parking window". Nice feature, it allows you to move a control from one parent to another without having to destroy and re-create the control.
But the keyword there is "temporarily". It is only temporarily if you next reparent the control. So it gets moved from the parking window to the new parent. If you don't actually reparent it then it will stay alive for ever on the parking window. Gobbling up resources until the program terminates. This is otherwise known as a leak. It can crash your program when Windows refuses to create another window when you've already created 10,000 of them.
The ControlCollection.Clear() method is especially harmful here. It does not dispose the controls, they all get moved to that parking window. If that's not intended, it rarely is, you'll have to call Dispose() on them yourself.
Objects in .NET become eligible for garbage collection when there's no way of getting at them. In this case, there will be a way of getting at the TabPage via the TabPages collection, until either it's removed from the collection or the tab control itself becomes eligible for collection.
Now when an object becomes eligible for garbage collection, that doesn't mean it's garbage collected straight away - the garbage collection runs at various times according to some fairly complex heuristics, and there are also "generations" of memory which make things harder to predict.
But basically:
You don't need to worry that an object that's been added to a collection will be mysteriously collected and cause problems
You generally don't need to worry that objects will leak memory forever. There are certainly situations where you do need to take some active steps to make sure that an object is eligible for collection when you're no longer using it, but they're relatively rare. (Typically they are related to static variables and/or events, in my experience.)
because soemthing has a reference to the controls they will not be disposed of.
yes the lifetime would be till the end of the procedure if you were not adding a reference to them to the colelction.
the clear will remove the objects from the collection and they will get garbage collected provided there are no other references to them (which there shuoldnt be in the situation you describe)
You add only a reference of the TabPage object to the collection not the object TmpTabPage. The tmpTabPage object in this case you use it only for allocating memory.