Actually, for the record, C# doesn't have this feature... <g> Here's the full story:

What you posted are just syntax errors which can be determined relatively
easily by the parser. VB6 had this too.

What our background compiler does is full semantic errors.

For example, the following is syntactically correct, but not semantically correct:

Class Foo
Private Sub Bar
End Sub
End Class

Sub Main
Dim a As New Foo
a.Bar
End Sub

In VB .NET, you get an error on "a.Bar" saying that Bar is Private and cannot be called.
In C#, you have to build to get errors like this.

There are a host of errors that a background compiler finds that a parser never will.
That's also why things like casing errors won't be found in C# during typing
- but only at compile

sqldataadapter x ;

that's syntactically correct, but not semantically correct since
sqldataadapter doesn't exist.

yag


>Alan,
>
>>> why not admit that VB.NET gives you an advantage because its background compiler gives you error info while coding - not having to wait for compilation.
>
>Actually, for the record, C# has this feature too...
>
>For example, if I'm writing code and I enter the following lines (the method def is missing the closing paren):
>
>
>private void HelloWorld(
>{
>}
>

>
>I immediately get the following three compiler errors in the VS.NET Task List:
>
>1. ") Expected"
>2. Identifier Expected
>3. Type Expected
>
>In addition, a small red "squiggly" line is placed after the opening paren to visually indicate where the compiler sees the problem. I get all of these "auto-magically" as I type--without manually recompiling.
>
>Regards,