Transition from Visual Basic 6.0 to Visual Basic.NET


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 17

Thread: Transition from Visual Basic 6.0 to Visual Basic.NET

  1. #1
    Jim Pragit Guest

    Transition from Visual Basic 6.0 to Visual Basic.NET


    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

  2. #2
    Dave Haskell Guest

    Re: Transition from Visual Basic 6.0 to Visual Basic.NET

    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.



  3. #3
    Matthew Solnit Guest

    Re: Transition from Visual Basic 6.0 to Visual Basic.NET

    "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



  4. #4
    Jim Pragit Guest

    Re: Transition from Visual Basic 6.0 to Visual Basic.NET


    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
    >
    >



  5. #5
    Jonathan Allen Guest

    Re: Transition from Visual Basic 6.0 to Visual Basic.NET

    > 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




  6. #6
    Mike Mitchell Guest

    Re: Transition from Visual Basic 6.0 to Visual Basic.NET

    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

  7. #7
    Evan Delay Guest

    Re: Transition from Visual Basic 6.0 to Visual Basic.NET

    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




  8. #8
    John Proffitt Guest

    Re: Transition from Visual Basic 6.0 to Visual Basic.NET


    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


  9. #9
    Jim Pragit Guest

    Re: Transition from Visual Basic 6.0 to Visual Basic.NET


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


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

    - Jim


  10. #10
    Matthew Solnit Guest

    Re: Transition from Visual Basic 6.0 to Visual Basic.NET

    "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



  11. #11
    Jonathan Allen Guest

    Re: Transition from Visual Basic 6.0 to Visual Basic.NET

    > 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
    >
    >




  12. #12
    Matthew Solnit Guest

    Re: Transition from Visual Basic 6.0 to Visual Basic.NET

    "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



  13. #13
    David A. Rothgery Guest

    Re: Transition from Visual Basic 6.0 to Visual Basic.NET

    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

  14. #14
    John Proffitt Guest

    Re: Transition from Visual Basic 6.0 to Visual Basic.NET


    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


  15. #15
    Jonathan Allen Guest

    Re: Transition from Visual Basic 6.0 to Visual Basic.NET

    > 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.




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center