Maybe I'm borrowing trouble, but I have wrapped my head around dynamically creating controls. I am building a form on the fly that allows the user to enter as many rows of data as they wish.
I have methods for creating the controls based on a button click and am aware that as long as my controls have the same ID on each PostBack then the ViewState will populate them with the data they had before the PostBack.
My question is: Say the user has added 5 rows and filled them out. The decides to delete row 3. The easiest approach is to just call parent.Controls.Remove("ID"). Does this update the ViewState so that I can just decrement my counter by 1 and renumber the remaining controls from 0 to 3 or do I need to keep track of which one was deleted and keep the numbering 0, 1, 3, 4?
Do do I have to do something to clear the ViewState's record of the deleted control?
When developing an ASP.NET Forms application, as long as you operate within the context of the ASP.NET Forms framework and objects between page load and post-backs you will be safe. Albeit, it is sometimes challenging to do without adding custom code. Handling that in the code behind is exactly the best place for this, for adding controls dynamically to a page.
When you remove the control, ViewState should be updated automatically as you are using a ASP.NET Forms method directly on a control when you call parent.Controls.Remove("ID"). In the case you are custom naming the controls, you will need to provide all the id's or names yourself so that they are distinct for the page. So here I am under the assumption you have custom named the control, and know what to really put in place for "ID".
ViewState is generally transparent to you as far as coding is concerned. Sometimes you may find yourself manually clearing ViewState between post-backs (like for a form with a password, when every visit to the page you need to clear the value). ViewState can also be turned off, so think about whether
or not your app needs the extra overhead for ViewState. On dynamic forms, I would do my best to implement adding controls or data binding to custom data sources in the code behind. The reason being is registering client-side scripts, so ASP.NET Forms framework knows about the scripts, and handling a custom id attribute or naming schemes client-side can be hard to debug or deal with from a binding standpoint.
I have personally integrated an ASP.NET Forms application with AngularJS 1.6, and while it was more difficult, and needed more configuration than with ASP.NET MVC, it was still possible and offered me a nice way to build dynamic forms out of ASP.NET's hands. However, binding back to your form values in the code behind requires looking and fetching values out of Request.Form Collection. If done in this manner, where your form is external to ASP.NET there will be no ViewState for those objects.
Does this update the ViewState so that I can just decrement my counter by 1 and renumber the remaining controls from 0 to 3 or do I need to keep track of which one was deleted and keep the numbering 0, 1, 3, 4?
As far as the strategy you are mentioning here a code sample would be most helpful. I have to make a lot of assumptions there to guess what might be happening. I could tell you it's okay, but you could still be missing something effecting the outcome in your personal results. When deleting a row, it will update the ViewState automatically. As far as keeping track of your numbering scheme for how you name your control Id's with distinct values, I would personally not leave gap's in the numbers, so stick to 0 to 3, and it should simplify your code and you will not have to track as much in the code behind or it will not effect your rendering logic. This way the controls bind uniquely back to your code behind during a post-back, and you can just iterate easily through the control collections, without worrying about naming schemes as much.
