I appreciate this is no longer supported by @leocb or @orapps44 but I'm posting in case anyone is still reading these and might be able to at least offer some advice... I also saw that @MKentV had offered to help maintain going forward just a few weeks ago!
I have a WinForms application using MaterialSkin. I have a panel on a form which gets dynamically populated with user controls which allow the users to view cases on a page, these are quite small and they can view around 100 user controls at a time, each control contains some labels and a button to go to the case details (button raises an event to navigate the case page)
when they change their filter the user controls are disposed and events are unsubscribed before clearing the panel of controls and then adding all of the new cases (user controls) based on their filter selection. This all works fine for a while until eventually I get the error "System.ComponentModel.Win32Exception: 'Error creating window handle.'". I checked the diagnostic tools in visual studio debugger and can see that the process memory continues to grow every time the page is refreshed with new controls. So I believe this to be caused by the handle limit of 10,000 being reached, suggesting that the controls are not actually being disposed by the call to Control.Dispose() method. I have iterated all controls in the panel and even down to controls of controls until I confirmed I had reached the bottom of the stack calling Dispose on everything. The events were unsubscribed using "Control.Event -= EventMethod" which I can see is successfully setting the event to null.
So I started to wonder if MaterialSkin has created some events tied to the controls which is preventing GarbageCollector from reclaiming them. In order to test this theory I created versions of my user controls which only use standard winforms controls hosted on a standard winform, the code-behind is identical other than pointing to the winforms versions of the controls. When I run this version and monitor the diagnostic tools in visual studio I can see that the process memory is now stable rather than continuously growing on every refresh and I was able to continue refreshing well beyond the point that the error occurred previously so am confident that regular winforms controls don't suffer the same issue.
Apologies for the large post but wanted to get all my investigations on here in the hope that somebody can point out where I am going wrong.
Is there some way I can tell MaterialSkin to dispose these controls?
I appreciate this is no longer supported by @leocb or @orapps44 but I'm posting in case anyone is still reading these and might be able to at least offer some advice... I also saw that @MKentV had offered to help maintain going forward just a few weeks ago!
I have a WinForms application using MaterialSkin. I have a panel on a form which gets dynamically populated with user controls which allow the users to view cases on a page, these are quite small and they can view around 100 user controls at a time, each control contains some labels and a button to go to the case details (button raises an event to navigate the case page)
when they change their filter the user controls are disposed and events are unsubscribed before clearing the panel of controls and then adding all of the new cases (user controls) based on their filter selection. This all works fine for a while until eventually I get the error "System.ComponentModel.Win32Exception: 'Error creating window handle.'". I checked the diagnostic tools in visual studio debugger and can see that the process memory continues to grow every time the page is refreshed with new controls. So I believe this to be caused by the handle limit of 10,000 being reached, suggesting that the controls are not actually being disposed by the call to Control.Dispose() method. I have iterated all controls in the panel and even down to controls of controls until I confirmed I had reached the bottom of the stack calling Dispose on everything. The events were unsubscribed using "Control.Event -= EventMethod" which I can see is successfully setting the event to null.
So I started to wonder if MaterialSkin has created some events tied to the controls which is preventing GarbageCollector from reclaiming them. In order to test this theory I created versions of my user controls which only use standard winforms controls hosted on a standard winform, the code-behind is identical other than pointing to the winforms versions of the controls. When I run this version and monitor the diagnostic tools in visual studio I can see that the process memory is now stable rather than continuously growing on every refresh and I was able to continue refreshing well beyond the point that the error occurred previously so am confident that regular winforms controls don't suffer the same issue.
Apologies for the large post but wanted to get all my investigations on here in the hope that somebody can point out where I am going wrong.
Is there some way I can tell MaterialSkin to dispose these controls?