Wednesday, August 20, 2008

Debugger side effects FTW

Trying to (quickly) get my generated form site working in Firefox...

The first problem was that getElementById was returning null when the client side validation function was firing. A quick look at the source and I see that the Name attribute is set but not the Id on the control that I a looking for. IE "copes" by looking at the Name if the Id is not there, Firefox though "follows the standard". Ok, so why is ASP.Net not generating an Id?

Due to time constraints I tried setting the Id when I create the control, but though it looks fine in the source and the validation works, now I don't get any data in the Text member after postback? Huh? I guess that ASP does not like it when it does not generate the Id, probably have to munge the ViewState to store my Id... No thanks.

So I am just playing in the debugger, trying to see what is populated after adding the control, maybe I can set the Id to be the same as the genereated Name... I add a watch for Control.ID, it's null, then I add a Watch for Control.ClientID, its "ctrl09", now if I just set the contr... wait a second, what?... the watch item for Control.ID just got updated with a value.

Accessing Control.ClientID causes Control.ID to be populated.

I look in the source, sure enough, for the control that I frigged with, the Id is defined. I add this after adding the control to the page:

   1: f.Control.ID = f.Control.ClientID;

And we still let ASP choose the value of the ClientId and hence the Name, but trick it into populating the Id also. (Which I really think that it should anyway...) The assignment is really only for clarity, as this works just as well:

   1: string MicrosoftIsTehSuck = f.Control.ClientID;

Which at least puts a little smile on my face...

No comments:

Post a Comment