Prev: Execute process even if webpage is closed
Next: Site looks differently when published
From: dp on 24 Jun 2010 12:53
Hi all,

I have a table in the source view of an aspx. When i save the aspx,
visual studio immediately marks it all as changed and has removed all
occurances of colspan from my td tags. Anyone got any ideas?

Cheers
--
D
From: Chris on 25 Jun 2010 06:22
I have the exact same problem - why does this happen and how can you turn it
off?

"dp(a)nowhere.com" wrote:

> Hi all,
>
> I have a table in the source view of an aspx. When i save the aspx,
> visual studio immediately marks it all as changed and has removed all
> occurances of colspan from my td tags. Anyone got any ideas?
>
> Cheers
> --
> D
> .
>
From: jb on 13 Jul 2010 08:28
I have some good news and some *really* bad news on this....

Firstly, the good news. The colspans are only removed where they are not
necessary, and do not change the behaviour of the HTML. For example, if you
have:

<table>
<tr>
<td colspan="2"></td>
</tr>
<tr>
<td colspan="2"></td>
</tr>
</table>

they *will* (both) be removed as they may as well not be there. However, if
you have:

<table>
<tr>
<td colspan="2"></td>
</tr>
<tr>
<td></td>
<td></td>
</tr>
</table>

the colspan will *not* be removed, as that would change the behaviour. In
other words, I find they seem to get that right. You may not like them being
removed for your own purposes, but it seems there's nothing you can do to
stop it.

Now the *bad* news. In doing the removal, VS sometimes "corrupts" your HTML
(a bit higher up in the source) by simply removing a bunch of characters in
an unrelated place, delivering simply incorrect HTML. Just for example, I
had a line (which had nothing to do with the change):

<td class="clsPartHeadBold" style="width: 100%">User Interface</td>

and after VS had made its colspan changes later on, this line got
"corrupted" to:

<td class="clsPartHeadBold" styUser Interface</td>

It's as though it's buffering(?) of lines simply went wrong, losing a number
of characters.

It seems this has something to do with size of the file and/or the
complexity/nesting of the tables. The lines it will change vary depending on
the content --- I cannot find any pattern. You guys may not have seen this
yet, but believe me it's waiting for you as your file content changes....

Worst of all, you have no idea this has happened. If you are "lucky" it
will make your HTML syntactically incorrect, so you will notice it. If you
are "unlucky" it will not cause an error but some of your content has been
removed, and you may not notice it till it's too late....

The only workaround is you have to go through every single colspan in your
code and figure & remove the ones VS will remove, so that it will not do any
removing of these itself. Then, you won't get the random corruptions.

I would love to report this and have MS solve it, but I don't really know
how to so that they will, especially since the only way I can reproduce is to
give them big .aspx files of mine, as if I edit them down the problem can go
away....

For me, this is a horrendous bug, having just moved from VS 2005 (which was
fine) and come across this once I start editing.
From: jb on 13 Jul 2010 12:30
I have a correction to make to my post above (in case anyone ever reads this).

Firstly, I stick by what I said about the colspan-removal behaviour. They
produce a "correct equivalent" --- the only time it would matter is if your
runtime code added further rows and (thought it could) rely on the existing
rows' colspans you typed in originally.

But for the "corruption" I have *finally* tracked it down and it is *not* to
do with changing colspans. Rather, my .aspx file had in one table:
<tr></tr>
i.e. an empty row *which contains no <td>s*. (This was not intentional: it
may have been from a previous version of VS design-mode editing, or after
hand editing). IN THIS CASE, VS2010 WILL CORRUPT UNRELATED LATER-TABLE-LINES
WHENEVER YOU HAPPEN TO EDIT STUFF LOWER DOWN IN THE PAGE. Removing such an
empty row (or putting in, say, a single <td></td>) thankfully solves the
problem, thank goodness. Only took 2 days to discover this........
From: d on 13 Jul 2010 16:57
Cheers for the info.

However, this is an example of VS trying to be too clever. It can
result in table corruption as i have found when using <%if ...%>
statements surrounding parts of the table.

Bottom line is VS should not automatically change my code - i would be
perectly happy with it flagging it and allowing me to change it if i
agree. Imagine if MS Office automatically changed your sentences
based on what the grammar checker deems to be correct.



On Tue, 13 Jul 2010 09:30:15 -0700, jb <jb(a)discussions.microsoft.com>
wrote:

>I have a correction to make to my post above (in case anyone ever reads this).
>
>Firstly, I stick by what I said about the colspan-removal behaviour. They
>produce a "correct equivalent" --- the only time it would matter is if your
>runtime code added further rows and (thought it could) rely on the existing
>rows' colspans you typed in originally.
>
>But for the "corruption" I have *finally* tracked it down and it is *not* to
>do with changing colspans. Rather, my .aspx file had in one table:
> <tr></tr>
>i.e. an empty row *which contains no <td>s*. (This was not intentional: it
>may have been from a previous version of VS design-mode editing, or after
>hand editing). IN THIS CASE, VS2010 WILL CORRUPT UNRELATED LATER-TABLE-LINES
>WHENEVER YOU HAPPEN TO EDIT STUFF LOWER DOWN IN THE PAGE. Removing such an
>empty row (or putting in, say, a single <td></td>) thankfully solves the
>problem, thank goodness. Only took 2 days to discover this........
 |  Next  |  Last
Pages: 1 2
Prev: Execute process even if webpage is closed
Next: Site looks differently when published