ASP.NET Web Control shows old data after the first postback

I'm having a weird problem with a custom Web Control in an ASP.NET forms application.

For a web application, I figured that it would save me a lot of time to create a class which inherits from CompositeControl which combines a label with some other control such as a TextBox or DropDownList. This composite control has several properties that wrap properties of the underlying properties (e.g.: EnteredText wraps TextBox.Text). The controls can be used for databinding in the same way as the regular ones, but instead of txtBox.Text = someObject.someProperty you use compositeControl.EnteredText = someObject.someProperty. These controls are then used on ASPX pages and ASCX user controls.

The first version of the web controls is written in C# and works perfectly. These controls are placed in the App_Code folder of the website. However, this folder was getting rather big and because of policy I have to write everything in VB.NET, so I decided to make a class library to put the VB.NET version of the controls in there, so that I don't have to translate the entire web application to VB.NET but only the controls.

However, the VB.NET version does not work. When I click the link in a GridView, it opens a popup and populates all the textboxes properly. When close the screen and click some other link from the same grid, the boxes are not populated properly and the data from the first postback is visible in the boxes. When using the debugger, I see that all boxes are populated with the proper data, and during the render phase the Text property of the underlying TextBox shows all of the new data. It just doesn't show that on screen. Retrieving the data after postback, like when pressing a save button, works as normal.

When I place a control from the App_Code folder on the same page, it works as expected and shows the new data and not the data from the previous postback.

Here are two paste bin URLs, the first goes to the working C# version and the second to the VB.NET version.

C# version: http://pastebin.com/SuWaHrMt

VB.NET version: http://pastebin.com/9aeV7St1

Here is an example how it's used in an ASCX file:

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="CustomControl.ascx.cs" Inherits="Controls_CustomControl" %>
<%@ Register Namespace="UI.CompositeControls" TagPrefix="cs" %>

<cs:TextBoxWithLabel ID="TextBoxWithLabel1" runat="server" LabelText="Voornaam" />
<cc:LabeledTextBox ID="tbwlVoornaam" runat="server" LabelTe开发者_高级运维xt="Voornaam" />

The cc prefix is specified in the web.config:

<pages theme="Default" controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID">
  <controls>
    <add assembly="CompositeControls" namespace="CompositeControls" tagPrefix="cc" />
  </controls>
  <namespaces>
    <add namespace="CompositeControls" />
  </namespaces>
</pages>

What am I missing here that makes the C# version work and the VB version not?

Thanks in advance! Feel free to ask questions if you want some clarification.

Update: I disabled the ViewState on the encompassing ASCX in question and it works:

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="CustomControl.ascx.cs" EnableViewState="false" Inherits="Controls_CustomControl" %>

My colleague found the following snippet:

If you reinsert controls with each round trip, each generation of dynamically created controls will pick up property values from the view state of the preceding set of controls. In many cases, you can avoid this problem by setting the EnableViewState property of the container control to false. In that case, no information about the dynamic controls is saved, and there is no conflict with successive versions of the controls.

I'm just not sure how this suddenly applies to the controls. Based on this MSDN article on ViewState I'm guessing that it happens because the Controls are added in the CreateChildControls method which occurs after the postback events.

Can someone explain what exactly is going on here?

---

In which browsers are you experiencing the issue? I recently had a similar problem in Firefox that was solved by just disabling Firebug caching. (http://i.stack.imgur.com/bRRjb.jpg)