Transition from Visual Basic 6.0 to Visual Basic.NET

[Jim Pragit]

I just downloaded the 'Transition from Visual Basic 6.0 to Visual Basic.NET'
(transitiondoc.doc) from Microsoft's website and there are few typos and
editing mistakes. In the hopes that a Microsoft employee is reading this
post, here what I found:

1) The Upgrade Wizard cell for Empty only has a period. It should say, "Empty
is converted to Nothing"

2) The Upgrade Wizard cell for Arrays is empty. It should say, "During upgrade,
you have the option to treat your arrays as zero lower bound, or to change
them to an array compatibility class, as in the following example:

Dim a(1 To 10) As String

is upgraded to:

Dim a As System.Array = VB6.NewArray(GetType(String), 1, 10)"

3) The Visual Basic 6.0 cell for Assignment says, "There are two forms of
assignment: Let assignment (the default) and Set assignment. Set assignment
cn.". It should say, "There are two forms of assignment: Let assignment (the
default) and Set assignment. Set assignment can be used only to assign object
references. The semantics of Let assignment are complex but can be summarized
as follows:

If the expression on the right-hand side of the Let statement evaluates to
an object, the default property of the instance is automatically retrieved
and the result of that call is the value that was assigned.

If the expression on the left-hand side of the Let statement evaluates to
an object, the default Let property of that object is called with the result
of evaluating the right-hand side. An exception to this rule applies if the
left-hand side is a variant containing an object, in which case the contents
of the variant are overwritten."

4) The Upgrade Wizard cell for File I/O says, "The file I/O statements are
upgraded to the corresponding functions. For example, the following code:
Open nput )". It should say, "The file I/O statements are upgraded to the
corresponding functions. For example, the following code:

Open "MyFile.txt" For Input As #1

is upgraded to:

FileOpen( 1, "MyFile.txt", _

OpenMode.Input )"

There are also a few other miscellaneous mistakes, such as extra blank spaces
and blank lines inserted at various places in the document.

--------------------------------

BTW, this sucks:

> From the Command window in Design mode, you can execute IDE commands,
> but you cannot run individual parts of your application.

Being able to test a routine from the Immediate window without having to
create a test program is a *huge* time saver. Please add this back in.

- Jim

[Dave Haskell]

Jim,

> BTW, this sucks:
>
> > From the Command window in Design mode, you can execute IDE commands,
> > but you cannot run individual parts of your application.
>
> Being able to test a routine from the Immediate window without having to
> create a test program is a *huge* time saver. Please add this back in.

Yes, absolutely yes, pretty please, with syntactic sugar on top!

It is probably the most useful feature of the VB IDE, easily beating
intellisense.

The ability to write a sub/function and immediately test it (without the need
to modify sub Main, compile and execute) is definitely invaluable.

[Matthew Solnit]

"Jim Pragit" <NoSpam@NoSpam.com> wrote in message
news:3a9682a1$1@news.devx.com...
> BTW, this sucks:
>
> > From the Command window in Design mode, you can execute IDE commands,
> > but you cannot run individual parts of your application.
>
> Being able to test a routine from the Immediate window without having to
> create a test program is a *huge* time saver. Please add this back in.

I think this functionality works because VB is an interpreted language. VB.NET
is compiled just like C++, so there is no way to implement the Immediate
feature. Being an interpreted language is also what allows VB to do instant
syntax checking as you type, which I sure do miss in VC++.

IMO they should change the window title back to "Debug" (VB1-4), because it
doesn't do anything "immediately".

-- Matthew Solnit

[Jim Pragit]

There's no way to compile just a single routine?

- Jim

"Matthew Solnit" <msolnit@nospam.yahoo-com> wrote:
>I think this functionality works because VB is an interpreted language.
VB.NET
>is compiled just like C++, so there is no way to implement the Immediate
>feature. Being an interpreted language is also what allows VB to do instant
>syntax checking as you type, which I sure do miss in VC++.
>
>IMO they should change the window title back to "Debug" (VB1-4), because
it
>doesn't do anything "immediately".
>
>-- Matthew Solnit
>
>

[Jonathan Allen]

> Being an interpreted language is also what allows VB to do instant
> syntax checking as you type, which I sure do miss in VC++.

Actually the reason VB had instant syntax checking is that it was line
terminated. When you hit enter, the IDE tries to parse the line. If it can,
it literally deletes what you typed and inserts its own version.

Languages like C cannot do this because there is no reliable way to
determine when a line has ended. The IDE could scramble your code just
because you left out a semi-colon.

--
Jonathan Allen

[Mike Mitchell]

On 23 Feb 2001 07:32:49 -0800, "Jim Pragit" <NoSpam@NoSpam.com> wrote:

>> From the Command window in Design mode, you can execute IDE commands,
>> but you cannot run individual parts of your application.
>
>Being able to test a routine from the Immediate window without having to
>create a test program is a *huge* time saver. Please add this back in.

They can't "add it back in". We're not talking about the next version
of VB6 here. VB.NET is a c-o-m-p-l-e-t-e-l-y new rewrite from the
ground up. There *is* nothing they could put it back into!

MM

[Evan Delay]

Have you got a link for that document?

"Jim Pragit" <NoSpam@NoSpam.com> wrote in message
news:3a9682a1$1@news.devx.com...
>
> I just downloaded the 'Transition from Visual Basic 6.0 to Visual
Basic.NET'
> (transitiondoc.doc) from Microsoft's website and there are few typos and
> editing mistakes. In the hopes that a Microsoft employee is reading this
> post, here what I found:
>
> 1) The Upgrade Wizard cell for Empty only has a period. It should say,
"Empty
> is converted to Nothing"
>
> 2) The Upgrade Wizard cell for Arrays is empty. It should say, "During
upgrade,
> you have the option to treat your arrays as zero lower bound, or to change
> them to an array compatibility class, as in the following example:
>
> Dim a(1 To 10) As String
>
> is upgraded to:
>
> Dim a As System.Array = VB6.NewArray(GetType(String), 1, 10)"
>
> 3) The Visual Basic 6.0 cell for Assignment says, "There are two forms of
> assignment: Let assignment (the default) and Set assignment. Set
assignment
> cn.". It should say, "There are two forms of assignment: Let assignment
(the
> default) and Set assignment. Set assignment can be used only to assign
object
> references. The semantics of Let assignment are complex but can be
summarized
> as follows:
>
> If the expression on the right-hand side of the Let statement evaluates to
> an object, the default property of the instance is automatically retrieved
> and the result of that call is the value that was assigned.
>
> If the expression on the left-hand side of the Let statement evaluates to
> an object, the default Let property of that object is called with the
result
> of evaluating the right-hand side. An exception to this rule applies if
the
> left-hand side is a variant containing an object, in which case the
contents
> of the variant are overwritten."
>
> 4) The Upgrade Wizard cell for File I/O says, "The file I/O statements are
> upgraded to the corresponding functions. For example, the following code:
> Open nput )". It should say, "The file I/O statements are upgraded to the
> corresponding functions. For example, the following code:
>
> Open "MyFile.txt" For Input As #1
>
> is upgraded to:
>
> FileOpen( 1, "MyFile.txt", _
>
> OpenMode.Input )"
>
> There are also a few other miscellaneous mistakes, such as extra blank
spaces
> and blank lines inserted at various places in the document.
>
> --------------------------------
>
> BTW, this sucks:
>
> > From the Command window in Design mode, you can execute IDE commands,
> > but you cannot run individual parts of your application.
>
> Being able to test a routine from the Immediate window without having to
> create a test program is a *huge* time saver. Please add this back in.
>
> - Jim

[John Proffitt]

kylix_is@hotmail.com (Mike Mitchell) wrote:
>On 23 Feb 2001 07:32:49 -0800, "Jim Pragit" <NoSpam@NoSpam.com> wrote:
>>
>>Being able to test a routine from the Immediate window without having to
>>create a test program is a *huge* time saver. Please add this back in.
>
>They can't "add it back in". We're not talking about the next version
>of VB6 here. VB.NET is a c-o-m-p-l-e-t-e-l-y new rewrite from the
>ground up. There *is* nothing they could put it back into!
>

Maybe eventually they can hack together an interpreted version of the runtime
for debugging. The only problem would be to maintain cosistency with the
regular compiler. How does VB6 do it?

JBP

[Jim Pragit]

"Evan Delay" <evandelay@evandelay.com> wrote:
>Have you got a link for that document?

http://msdn.microsoft.com/vbasic/tec...de/default.asp

- Jim

[Matthew Solnit]

"Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
news:3a96c52f@news.devx.com...
> > Being an interpreted language is also what allows VB to do instant
> > syntax checking as you type, which I sure do miss in VC++.
>
> Actually the reason VB had instant syntax checking is that it was line
> terminated. When you hit enter, the IDE tries to parse the line. If it can,
> it literally deletes what you typed and inserts its own version.
>
> Languages like C cannot do this because there is no reliable way to
> determine when a line has ended. The IDE could scramble your code just
> because you left out a semi-colon.

I am not an expert, but it sounds like you are refuting your own statement. If
the issue is knowing when the line ends, then any language's IDE could do
instant syntax checking as soon as the semicolon (or equivalent) is typed.

I remember that another language I worked with had "immediate" functionality:
LISP. Also an interpreted language. Coincidence?

AFAIK the logic used to +interpret+ code at run-time can also be used to
interpret it at design time, and this is how instant syntax checking (and the
Immediate window) works.

-- Matthew Solnit

[Jonathan Allen]

> I am not an expert, but it sounds like you are refuting your own
statement. If
> the issue is knowing when the line ends, then any language's IDE could do
> instant syntax checking as soon as the semicolon (or equivalent) is typed.

That is easier said then done, especially if the IDE also reformats what you
typed like VB6 does. Lets say you wrote something like this...

if (x==10)
for (int i=0; i<10; i++)
X += i;

The IDE must attempt the syntax check four times before it finds a
terminating semicolon. And if you want syntax checking on the if line before
you type anything else, you need to attempt the syntax check after each
closing paren. Also, you have to scan several lines, not just the current
one.

The point I'm getting at is C style languages lack the consistency to make
line based syntax checking feasible. But as you said, that is not the only
way you can do it.

> AFAIK the logic used to +interpret+ code at run-time can also be used to
> interpret it at design time, and this is how instant syntax checking (and
the
> Immediate window) works.

VB6 has a two-step syntax checking method. The second step being controlled
by a checkbox in the project settings.
Step 1: Parse the line for syntax errors and reformat when the cursor
leaves it.
Step 2a: Check for all other compilation errors when the code is
compiled.
Step 2b: Check for all other compilation errors code it interpreted.

Step 2 version b, is what we lost. Microsoft could have built a VB.Net
interpreter, but for whatever reason chose not to.

VB.Net appears to use a variation of the above.
Step 1: Parse the line for syntax errors when the cursor leaves it.
Step 2: Check for all other compilation errors when the code is
compiled.

In order to give us the immediate feedback we are used-to, VB.Net literally
runs a compiler in the background. It uses this compiler to constantly
update the error messages, giving us far more detail than before.

Currently C# does not have this background compiler. However, there is no
obvious reason why it cannot have it in the future.

In conclusion, the loss of the interpreter and immediate window, while
unfortunate, has nothing to do with VB's syntax checking ability.

--
Jonathan Allen

My Bigfoot email account was rejecting messages for no apparent reason.
Therefore I am now using greywolf@cts.com as my email address.



"Matthew Solnit" <msolnit@nospam.yahoo-com> wrote in message
news:3a9925ac@news.devx.com...
> "Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
> news:3a96c52f@news.devx.com...
> > > Being an interpreted language is also what allows VB to do instant
> > > syntax checking as you type, which I sure do miss in VC++.
> >
> > Actually the reason VB had instant syntax checking is that it was line
> > terminated. When you hit enter, the IDE tries to parse the line. If it
can,
> > it literally deletes what you typed and inserts its own version.
> >
> > Languages like C cannot do this because there is no reliable way to
> > determine when a line has ended. The IDE could scramble your code just
> > because you left out a semi-colon.
>
> I am not an expert, but it sounds like you are refuting your own
statement. If
> the issue is knowing when the line ends, then any language's IDE could do
> instant syntax checking as soon as the semicolon (or equivalent) is typed.
>
> I remember that another language I worked with had "immediate"
functionality:
> LISP. Also an interpreted language. Coincidence?
>
> AFAIK the logic used to +interpret+ code at run-time can also be used to
> interpret it at design time, and this is how instant syntax checking (and
the
> Immediate window) works.
>
> -- Matthew Solnit
>
>

[Matthew Solnit]

"Jonathan Allen" <greywolf@cts.com> wrote in message
news:3a9aae0d@news.devx.com...
> In conclusion, the loss of the interpreter and immediate window, while
> unfortunate, has nothing to do with VB's syntax checking ability.

Okay.

> In order to give us the immediate feedback we are used-to, VB.Net literally
> runs a compiler in the background. It uses this compiler to constantly
> update the error messages, giving us far more detail than before.

But now Jim's complaint seems more reasonable. Why can't they give us Immediate
functionality, using the same compile-on-demand?

-- Matthew Solnit

[David A. Rothgery]

Matthew Solnit <msolnit@nospam.yahoo-com> wrote:
> "Jonathan Allen" <greywolf@cts.com> wrote in message
> > In order to give us the immediate feedback we are used-to, VB.Net
> > literally runs a compiler in the background. It uses this compiler
> > to constantly update the error messages, giving us far more detail
> > than before.
>
> But now Jim's complaint seems more reasonable. Why can't they give us
> Immediate functionality, using the same compile-on-demand?

Because it would take time that Microsoft doesn't have at this point.
From a purely marketing point of view, vb.NET really ought to be
shipping _now_.

--
Dave Rothgery
Picking nits since 1976
drothgery@myrealbox.com
http://drothgery.editthispage.com

[John Proffitt]

David A. Rothgery <drothgery@myrealbox.com> wrote:
>From a purely marketing point of view, vb.NET really ought to be
>shipping _now_.
>

Fortunately (or conceivably unfortunately, depending on your point of view)
the marketing types are not in charge of building the code.

JBP

[Jonathan Allen]

> Because it would take time that Microsoft doesn't have at this point.
> From a purely marketing point of view, vb.NET really ought to be
> shipping _now_.

Hopefully that is the only reason. Every version of Basic I've ever seen has
had an immediate mode, this is no time stop that tradition.

--
Jonathan Allen

My Bigfoot email account was rejecting messages for no apparent reason.
Therefore I am now using greywolf@cts.com as my email address.