I am having a problem whilst migrating a web application from ASP.NET 1.1 to ASP.NET 2.0. One of my user controls has a textbox that is not firing its text changed event.

The textbox is created at run time in a CreateChildControls override on the user control (ph is a placeholder in the .ascx file):

Protected Overrides Sub CreateChildControls()

      Dim txtTextBox As New System.Web.UI.WebControls.TextBox()
        txtTextBox.ID = "foo"
        ph.Controls.Add(txtTextBox)
        AddHandler txtTextBox.TextChanged, AddressOf Me.txtTextBox_TextChanged

End Sub

To ensure the control gets built early enough to register the event, in Page_Init I have:

...

Me.EnsureChildControls()

...

And I have the handler for the TextChanged event here:

Private Sub txtTextBox_TextChanged(ByVal sender As System.Object, ByVal e As System.EventArgs)

     <...Event code...>

End Sub

Finally, some javascript is squirted out onto the page. This sets the text in the textbox based on a user action (to somethig different to what was there), and then forces the postback by hooking into __doPostback (ctrl is set in javascript to the txtTextBox element):

...

ctrl.value = 'some new value';
  __doPostBack('','');

...

So - what is happening:

The javascript operates correctly, and I see the text value of the textbox change momentarily to the correct value, the page posts back (and I have even verified that the form values coming back to the parent page are indeed the correct text value). However, I have set a breakpoint, and know that the TextChanged event does not fire on the textbox. The event is designed to set the text into a Session variable. At a later stage in my code, this value in the Session variable is loaded back into the textbox - so without the event firing, the textbox just reverts to what was previously in the session and gets set back to what it was before.

Some other info: 

• Obviously since the page is posting back, __doPostBack is present. If the __doPostBack function is not on the page from other controls, I call GetPostBackEventReference to ensure it gets sent down.
• I have tried adding the TextChanged handler before and after (as in this example) adding the textbox to the placeholder - neither works.
• In the above example I do not set the __EVENTTARGET parameter of __doPostBack since I have read that the TextChanged event is triggered regardless of what does the post back (i.e. the new form value in the textbox is compared with ViewState to decide whether to raise the event). In my frustration though, I have tried setting the __EVENTTARGET parameter to (what I think is) the correct value (Me.UniqueId.Replace(":", "$") & "$foo") and the event still doesn't fire.
• I have made no code changes or viewstate changes when migrating - and this all works perfectly in ASP.NET 1.1!!!
• Given how close this is to working - maybe it has got something to do with a different page lifecycle in ASP.NET 2.0?

Please help - this is driving me nuts!

Mark

Cracked it - one thing I didn't put in the post above for code brevity (and the fact I didn't think it mattered) is that the textbox is set readonly (I only want the javascript to enter text into the textbox, not the user):

txtTextBox.ReadOnly = True

There is a change between ASP.NET 1.1 and 2.0 that even though a changed textbox value will be sent back in the post variables, the server will ignore it if the textbox is readonly (i.e. it won't load the new value into the 'Text' property of the textbox), hence the TextChanged event won't fire. This is a security issue addressed by Microsoft to prevent a user circumventing the readonly status of a textbox. They have a workaround where necessary by setting the textbox readonly using the attributes instead:

txtTextBox.Attributes.Add("readonly", "readonly")

Techincally this means the server doesn't know the textbox is readonly and hence follows the correct (IMHO) method of processing the form values (if something must really be readonly for security puposes, and you know this on the server, there are much better ways to ensure data doesn't get meddled with!). Some more info and related info can be found in these posts: 

http://scottonwriting.net/sowblog/posts/4965.aspx

http://west-wind.com/weblog/posts/3939.aspx

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=102065

Cheers,

Mark