Prev: Execute process even if webpage is closed
Next: Site looks differently when published
From: jb on 14 Jul 2010 04:49
I do not disagree with anything you say. (I presume by "table corruption"
you mean that the colspan changes do not deliver the correctly laid out table
in your circumstances, which is nowhere near as bad as actually chopping out
random partial bits of HTML elsewhere in your document, as my problem is/was!)

I was merely commenting, for those who read, that in, say, the plain case of
a table with no dynamics/%ifs etc., its changes actually deliver the same
table layout, rather than getting it wrong. We can guess that they must
build their own representation of your table's rows & columns with your input
colspans and then spit it back out with their "factored" colspans, all
doubtless in the name of attempting to allow you to edit it. Yours is the
only thread on the net discussing this behaviour, which has changed from
previous versions.

"d(a)nowhere.com" wrote:

> 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........
> .
>
From: d on 15 Jul 2010 16:30
Absolutely - i guess we can say that there are two problems. The one
you found is clearly bad - corruption of HTML is very bad, and should
not happen, although i guess the mitigation is that is caused in the
unusal case of specifying a table with no columns (maybe there are
others out there too). I don't know if anyone would do this
purposefully to add the definition at run time, but this kind of
corruption is going to make problem solving very difficult.

The second problem has less severe consequences but is extremely
annoying. I think it is a more normal thing to do to put parts of a
table in <%if .. %> statements. I certainly do it quite a lot. The
most annoying thing is you only normally notice it one the page runs,
and you have already saved this automatic and unwanted 'optimisation'.
I have one page that has a very complicated table with several <%if
%>'s in and if i make a change completely unrelated to the table say a
lot further down the page, save it, run it all looks fine. However
after this first save, the auto 'optimsiation' happens, if i don't
notice it because i am working on a different section of the page,
make a further change and save, run it - i find a corrupted table. The
easiest way i have found out of this (other than backing up the page
before every change i make), if i end up doing this, is to copy my
latest change to the clipboard, keep pressing Undo until i get back to
the point the table is corrected, and pasting back in my latest
changes. I am still waiting for the day where i make my latest
change, save and close, and become completely knackered and have to
spend ages rebuilding the table.

I think MS needs to address these problems. I don't know if there are
any other areas where VS will automatically try and optimise my code
for me and mess it up, but my view is there should not be any
automatic optimisation - just flag it like in Office - maybe even with
the same green squiggly line, with the red squiggly line for errors.

Are these two issues causing anybody else any headaches, and has
anyone found any neat setting or reg edit that can stop VS doing this?

Cheers
--
d


On Wed, 14 Jul 2010 01:49:08 -0700, jb <jb(a)discussions.microsoft.com>
wrote:

>I do not disagree with anything you say. (I presume by "table corruption"
>you mean that the colspan changes do not deliver the correctly laid out table
>in your circumstances, which is nowhere near as bad as actually chopping out
>random partial bits of HTML elsewhere in your document, as my problem is/was!)
>
>I was merely commenting, for those who read, that in, say, the plain case of
>a table with no dynamics/%ifs etc., its changes actually deliver the same
>table layout, rather than getting it wrong. We can guess that they must
>build their own representation of your table's rows & columns with your input
>colspans and then spit it back out with their "factored" colspans, all
>doubtless in the name of attempting to allow you to edit it. Yours is the
>only thread on the net discussing this behaviour, which has changed from
>previous versions.
>
>"d(a)nowhere.com" wrote:
>
>> 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........
>> .
>>
First  |  Prev  | 
Pages: 1 2
Prev: Execute process even if webpage is closed
Next: Site looks differently when published