Table in Content Area becomes 26x width of screen

[John Kotuby]

Here's a good one everybody. Probably another dumb programmer mistake, but I
can't find it yet.
The application I'm working on uses a Master Page which always displays a
banner and links at the top, a vertical menu (3rd party) on the left and a
footer.

A very simple content page consists of a centered table defined at static
width of 500px. It contains a number of HTML input textboxes, an asp:button
for submit, an asp:lisbox(1 row) and an HTML input Reset button. The purpose
is to allow the user to edit and update their own contact information. I use
a good bit of simple HTML as it renders faster and uses less server
resources.

Upon initial page-load the page gathers the user information from a SQL
Server 2005 table and displays it.
Upon postback to itself, the page the updates the SQL table, and re-selects
the data so that when the page again displays, the user can see the result
of his changes. All of that is working fine.

I have added some server-side data validation. If one of the fields does not
pass muster I assemble and display a javascript alert box, which pops up
just before the page refresh, thusly...

Response.Write("<script type=text/javascript>")
Response.Write("alert('View All must be either Y or N')")
Response.Write("</script>")

It works fine if I again Select the table data and plug the variables
associated with the input fields before allowing the page to re-display.
But I realized that re-initializing the data if the validation fails and no
Table update occurs, would put the page back to the initial state...and the
user must re-enter all the fields. Yes, I plan to implement client-side
validation, but server-side validation is also important.

So , in the case of a validation failure, I skipped the Select from the SQL
table and just used the data in the fields as passed in the postback, in
order to retain state (like in the classic ASP days). However, when I do
this the, page reload results in a form table that is 26 times the width of
the full-screen browser window! Yikes. My first thought is that there is
some data in the post-backed variables that is incredibly long, thereby
stretching the table width to enormous proportions.

I have spent 6 hours examining the data and cannot find any untrimmed string
data. It all looks correct.

So, has anybody seen such behavior before and is there another place to look
besides the data in the input text fields?

Thanks to all

 

[Guest]

My first thought is that there is
some data in the post-backed variables that is incredibly long, thereby
stretching the table width to enormous proportions.

it should be something within the HTML table: either a long text, or
an object (like <div>) that break the width

 

[John Kotuby]

Thanks for the response Alexey,

I have not found any long data that may have stretched the table.
With the Master Page and 3rd party menuing, the resulting HTML source (in
the browser) is very hard to follow and includes numerous DIVs and Tables
that are generated in addition to the Table that I create for data entry.

However, by not using the ad hoc Javascript alert sent back in the Response
object, the problem went away, even though I have used this technique in
other pages without a problem.

Instead of:
Response.Write("<script type=text/javascript>")
Response.Write("alert('View All must be either Y or N')")
Response.Write("</script>")

When server-side validation fails I now place the error message ('View All
must be either Y or N') in a variable which then displays on the page
itself.

Furthermore, now that I have also added Validation Server Controls for
client-side validation, I will use their built-in feature of displaying the
message in an alert box for any error that slips by the client-side
validation and is caught on the server.

Well, at least I got past the problem. Maybe someday I will discover exactly
what the culprit was.

Thanks again for your input.

 

[Lloyd Sheen]

Thanks for the response Alexey,

I have not found any long data that may have stretched the table.
With the Master Page and 3rd party menuing, the resulting HTML source (in
the browser) is very hard to follow and includes numerous DIVs and Tables
that are generated in addition to the Table that I create for data entry.

However, by not using the ad hoc Javascript alert sent back in the
Response object, the problem went away, even though I have used this
technique in other pages without a problem.

Instead of:
Response.Write("<script type=text/javascript>")
Response.Write("alert('View All must be either Y or N')")
Response.Write("</script>")

When server-side validation fails I now place the error message ('View All
must be either Y or N') in a variable which then displays on the page
itself.

Furthermore, now that I have also added Validation Server Controls for
client-side validation, I will use their built-in feature of displaying
the message in an alert box for any error that slips by the client-side
validation and is caught on the server.

Well, at least I got past the problem. Maybe someday I will discover
exactly what the culprit was.

Thanks again for your input.

John,

If you are using IE download the IE Developer toolbar. I have used that
many times to figure out what is happening. The generated HTML is hard to
see at the best of times but if you use Ajax it is impossible since even
view source does not work correctly. There is an option to see elements by
clicking on them and you can change properties to see the difference in
behaviour. A great tool.

Hope this helps
Lloyd Sheen

 

[John Kotuby]

Thanks for the tip!

John,

If you are using IE download the IE Developer toolbar. I have used
that many times to figure out what is happening. The generated HTML is
hard to see at the best of times but if you use Ajax it is impossible
since even view source does not work correctly. There is an option to see
elements by clicking on them and you can change properties to see the
difference in behaviour. A great tool.

Hope this helps
Lloyd Sheen