TECH TIP: Break - Edit - Continue alternatives


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

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

Thread: TECH TIP: Break - Edit - Continue alternatives

  1. #1
    Larry Serflaten Guest

    TECH TIP: Break - Edit - Continue alternatives

    VB.Net has dropped the BEC (Break, Edit, and Continue) functionality,
    but there are alternatives that will assist in debugging. Using the Command
    window in Immediate mode, the values of some of the variables can be
    changed. This procedure alone can help you get through buggy code by
    inserting more correct values where needed.

    To change a variable, select View/Other Windows/Command Window from
    the IDE menu, then enter 'immed' after the prompt in the command window.
    You can then issue commands from the current development language by
    typing in the command and pressing Enter. (Help says '>' is needed ahead of
    the command, I found otherwise using VB.Net.)

    After inserting valid values, you are able to continue on to more debugging
    if necessary. There are times, however, that a rewrite of a section of code
    needs to be done. The IDE won't let you add or change code while the
    program is running, but you really don't want to forget where it was, or what
    it was that needed doing. Again, to get by that section temporarily, you can alter
    a few values, but to remember where that section is located, you can add a
    bookmark that will show up in the task list.

    To add a bookmark to the task list, right click on the left margin of the code
    window, at the place you want to return to, then select 'Add Task List Shortcut'
    from the context menu. Open the Task List if it is not already open
    (View/Other Windows/Task List) then edit the Description field of the new task
    to indicate what must be done at that location.

    Using the Immediate window will let you call into your code, to test a function,
    plus other uses, so the only thing lacking from the classic BEC functionality is the
    ability to write new code while your program is running. Unless your a seat-of-your-
    pants type of coder, you might want to consider the ramifications any new code
    will have on other areas of your project before making changes. Having to stop the
    program, and cycling through the Task List may help remind you to consider what
    you are going to change, before making the change permanent. In essence, the RAD
    funtionality of BEC is not lost, you just have to get used to a few new processes!


    <VS Editors - You may publish this tip free of charge, all I ask is that you credit the
    source!>

    Larry Serflaten
    AKA: LFS









  2. #2
    Rob Teixeira Guest

    Re: TECH TIP: Break - Edit - Continue alternatives


    "Larry Serflaten" <serflaten@usinternet.com> wrote:
    >
    >To change a variable, select View/Other Windows/Command Window from
    >the IDE menu, then enter 'immed' after the prompt in the command window.
    >You can then issue commands from the current development language by
    >typing in the command and pressing Enter. (Help says '>' is needed ahead

    of
    >the command, I found otherwise using VB.Net.)
    >


    The Command and Immediate functionality share the same window. The '>' character
    appears automatically in front of any line under Command mode, but does not
    appear (and is not used) in Immediate mode.
    VS commands (such as SaveAll, etc.) can only be invoked while in Command
    mode.

    To switch from Command mode to Immediate mode: immed[enter]

    To switch from Immediate mode to Command mode: >Cmd[enter]

    -Rob

  3. #3
    Phil Weber Guest

    Re: TECH TIP: Break - Edit - Continue alternatives

    > To VS Editors...

    Larry: I don't know if the editors follow this group. You may want to repost
    your tip to talk.editors.vsm.
    ---
    Phil Weber



  4. #4
    Larry Serflaten Guest

    Re: TECH TIP: Break - Edit - Continue alternatives


    "Rob Teixeira" <RobTeixeira@@msn.com> wrote
    >
    > >(Help says '>' is needed ahead of
    > >the command, I found otherwise using VB.Net.)
    > >

    >
    > The Command and Immediate functionality share the same window. The '>' character
    > appears automatically in front of any line under Command mode, but does not
    > appear (and is not used) in Immediate mode.
    > VS commands (such as SaveAll, etc.) can only be invoked while in Command
    > mode.


    I guess I was a bit confused myself. Here is what I read in the Docs:

    ms-help://MS.VSCC/MS.MSDNVS/vsintro7/html/vxurfImmediateModeCommandWindow.htm
    <quote>
    Note To issue a single command Visual Studio.NET while in Immediate mode, you must
    preface the command with a greater than sign (>). For example, to switch to Command
    mode from Immediate mode, you must preface the command with a greater than sign (>).
    To enter multiple commands, switch to Command mode.
    </quote>

    I now find that you can enter VS commands in the command window, while in Command
    mode, and you can enter VS commands in Immediate mode if you preface them with the > char.

    I have issued a SaveAll command from Immediate mode, using the > ahead of the command.

    I originally read the docs as meaning Immediate mode commands needed the > character.
    Isn't that what the first sentence in the Note says? <g>

    To VS Editors - simply remove the parentheses in the tip "(Help says...)", and all will be fine....

    LFS







  5. #5
    Larry Serflaten Guest

    Re: TECH TIP: Break - Edit - Continue alternatives


    "Phil Weber" <pweber@_fawcette.com> wrote in message news:3bd9ddf1$1@news.devx.com...
    > > To VS Editors...

    >
    > Larry: I don't know if the editors follow this group. You may want to repost
    > your tip to talk.editors.vsm.
    > ---
    > Phil Weber



    Great, that gives me a chance to edit it!

    (I hate it when that happens!)
    <g>
    LFS






  6. #6
    Rob Teixeira Guest

    Re: TECH TIP: Break - Edit - Continue alternatives


    "Larry Serflaten" <serflaten@usinternet.com> wrote:
    >
    >I originally read the docs as meaning Immediate mode commands needed the
    > character.
    >Isn't that what the first sentence in the Note says? <g>


    Nah, it says that in order to invoke commands (such as the menu/DTE commands)
    in immediate mode, you need to preface the line with a '>'.
    You don't need (and shouldn't use) the '>' character to run an expression
    or statement.
    But yeah, the docs could have been a little more clear on that.

    -Rob

  7. #7
    Gregor R. Peisker Guest

    Re: TECH TIP: Break - Edit - Continue alternatives

    Hi Larry,

    > Using the Command window in Immediate mode,
    > the values of some of the variables can be
    > changed.


    in addition to that, you can also change variables in the Locals window, like in
    old VB.

    Gregor





  8. #8
    Cali LaFollett Guest

    Re: TECH TIP: Break - Edit - Continue alternatives

    Kathleen,

    Comments inline....

    > > 2. CONTEXT: Intellisense - Shift space doesn't work in some ways as it

    > used
    > > to. I.e. if you paste in some code like
    > >
    > > Imports System.Web.UI.WebControls
    > >
    > > ... you SHOULD be able to put your cursor after "Web.", and if UI is
    > > unique, it just "slides" over that to the next dot. As it did in VB6.

    >
    > Maybe I don't understand you, but VB.NET should not assume you have

    already
    > referenced your namespaces. If I understand what you are suggesting, I
    > dsiagree with it.


    I think what he is talking about is that when you hit the "Tab" key it does
    something like the following:

    Imports System.Web.UI
    ~~~~~~~~~~~~~~^~~
    ....hitting the "Tab" key here it does this...

    Imports System.Web.UIUI

    instead of moving the cursor after the "I" in "UI" because "UI" is unique in
    the Intellisense list.

    > I am a little confused by this. My experience is that Intellisense is

    better
    > and more aggressive.


    I have to disagree in a small way. One of the things that I liked before is
    that if you had an object variable in VB6 and already had a method call
    after the period, if you retype the period the Intellisense would make the
    "selected" intellisense item the method or property that you already have
    typed in the editor.

    What happens now in VB.NET's IDE is if you retype the period between an
    object variable and an already inplace method call, Intellisense starts at
    the very first item in the list and doesn't move to the currently called
    method. And again, if you hit the "Tab" key, it doesn't replace your already
    typed in method it just prepends that text with the newly selected
    Intellisense selection.

    It's just a little quirky compared to how it used to work and I am still not
    sure if I like it. Old habits of how I used to work in the VB6 IDE are a
    little hard to break.
    --
    Regards,
    Cal



  9. #9
    Kathleen Dollard Guest

    Re: TECH TIP: Break - Edit - Continue alternatives

    Richard,

    > 2. CONTEXT: Intellisense - Shift space doesn't work in some ways as it

    used
    > to. I.e. if you paste in some code like
    >
    > Imports System.Web.UI.WebControls
    >
    > ... you SHOULD be able to put your cursor after "Web.", and if UI is
    > unique, it just "slides" over that to the next dot. As it did in VB6.


    Maybe I don't understand you, but VB.NET should not assume you have already
    referenced your namespaces. If I understand what you are suggesting, I
    dsiagree with it.

    > 2. CONTEXT: Intellisense - Shift space doesn't work in some ways as it

    used
    > to. I.e. if you paste in some code like
    >
    > Imports System.Web.UI.WebControls
    >
    > ... you SHOULD be able to put your cursor after "Web.", and if UI is
    > unique, it just "slides" over that to the next dot. As it did in VB6.


    I am a little confused by this. My experience is that Intellisense is better
    and more aggressive.

    Kathleen





  10. #10
    Richard Curzon Guest

    Re: TECH TIP: Break - Edit - Continue alternatives

    Some other things people might not have noticed.

    1. CONTEXT: One thing that makes DOTNET unfriendly to VB6 afficionados is
    the loss of many handy features. One that appeared to be trashed was Shift
    F2 to take you from a procedure/method reference... to the actual
    definition.... which didn't work in Beta 1.

    Alternatives were there, but finding using the object browser, or by text
    search, was a sucky replacement (tech term). It looked like the non-VBers
    on the IDE team throwing out good ideas from VB without bothering to
    understand them.

    TIP: Shift F2 works as of beta 2, takes you to a procedure/method definition
    from a reference. Control Shift F2 works to cycle through a ring of recent
    cursor locations.


    2. CONTEXT: Intellisense - Shift space doesn't work in some ways as it used
    to. I.e. if you paste in some code like

    Imports System.Web.UI.WebControls

    .... you SHOULD be able to put your cursor after "Web.", and if UI is
    unique, it just "slides" over that to the next dot. As it did in VB6.

    If not unique, it should shows the popup choice window with first valid
    choice active ... Hit space and it slides over to the next. Move the cursor
    past the dot, same thing.

    That doesn't work in DotNet. You get a popup, but the intellisense has no
    default, even if current text is valid.

    TIP: if you move the cursor past the dot AND the first character following
    the dot, it seems to work almost as well. Weird, hope that's a beta 2 bug.
    Also, if you'd rather that the correct case showed up, even if it's case
    insensitive, that'll do it.

    ---

    Any other usability hints? However trivial, they might help smooth things
    for some of us...

    regards
    Richard.





  11. #11
    Richard Curzon Guest

    Re: TECH TIP: Break - Edit - Continue alternatives

    Hard to describe... <g>

    One criticism I always make of the XP guys and their unit testing is that
    they pretend to be so responsive to user needs.

    But when it comes to rich UI, the knuckledusters come out, they browbeat the
    user into giving it up. Not because it's the right thing for the app, but
    because it's so hard to write code to unit test rich GUIs. Plus the more
    features in the GUI, the more changes, the more changes to unit tests.

    Why do I bring that up?

    Cuz dotnet IDE GUI is about as rich as they come, even intellisense has so
    many little features and modes most of us probably never use them all.
    Can't imagine writing code driven unit tests for them.

    Bottom line, I can't think of a better way to say what I said, but maybe
    it's something you never did. <g> Anyway, it's not a major thing, just
    something I happen to do a few times a day during coding. There are other
    ways to get the dot-qualifications right when you paste code in.

    I'm sure you've come across some good little tips though Kathleen, give em
    up!

    regards
    Richard.

    --
    ---
    Hate spam? Do what you can: www.spamcop.net customer



  12. #12
    Mark Hurd Guest

    Re: TECH TIP: Break - Edit - Continue alternatives

    I also hope that needing to invoke intellisense after the first character is
    is a bug, but I worry that it survived through beta 1 and 2.

    It may be related to the .UIUI problem described elsewhere in this thread. I
    think that may be due to a decision that the VB6 scenario of

    .wri|VarName

    where | is the cursor and the matching method is "Write". If you now invoke
    intellisense, it 'eats' VarName and just leaves you with

    .Write

    Anyway, these are problems that we who are used to the VB5/6 techniques are
    going to learn to override more slowly than picking up the new language.
    (Where these are not bugs or features that weren't completed in time for
    release I'm not compaining here!)

    I used the C++ debugger for VB5/6 projects (mainly for remote debugging, but
    also for some threading issues) and so I now find it frustrating that I go for
    F11 as single step when debugging a disassebly (often a caught GPF), but F8
    when debugging VB.NET.

    Regards,
    Mark Hurd, B.Sc.(Ma.) (Hons.)






  13. #13
    Phil Weber Guest

    Re: TECH TIP: Break - Edit - Continue alternatives

    > I used the C++ debugger for VB5/6 projects...and so I now find
    > it frustrating that I go for F11 as single step when debugging a
    > disassembly..., but F8 when debugging VB.NET.


    Mark: You can change that. On the VS.NET Start Page, click on "My Profile"
    and set your profile to "Visual C++ Developer." You can also customize
    keyboard shortcuts by selecting Tools -> Options -> Environment -> Keyboard.
    ---
    Phil Weber



  14. #14
    Mark Hurd Guest

    Re: TECH TIP: Break - Edit - Continue alternatives

    "Phil Weber" <pweber @ fawcette.com> wrote in message
    news:3be96dcc$1@147.208.176.211...
    > > I used the C++ debugger for VB5/6 projects...and so I now find
    > > it frustrating that I go for F11 as single step when debugging a
    > > disassembly..., but F8 when debugging VB.NET.

    >
    > Mark: You can change that. On the VS.NET Start Page, click on "My Profile"
    > and set your profile to "Visual C++ Developer." You can also customize
    > keyboard shortcuts by selecting Tools -> Options -> Environment -> Keyboard.
    > ---
    > Phil Weber


    I know I can adjust the settings, or the profile.

    However, I was going to say "surprising" where I typed "frustrated" and I was
    really referring to my own internal reflexes.

    That is, I'm "strongly surprised" that my fingers distinguish a difference
    when the IDE doesn't look that much different during the two debugging
    scenarios.

    Regards,
    Mark Hurd, B.Sc.(Ma.) (Hons.)



  15. #15
    Jeff Pipes Guest

    Re: TECH TIP: Break - Edit - Continue alternatives


    What good is the immediate window if you can't run code?

    ?len("asdf")
    The expression cannot be evaluated while in design mode.
    ?22/7
    The expression cannot be evaluated while in design mode.

    -Jeff

    "Rob Teixeira" <RobTeixeira@@msn.com> wrote:
    >
    >"Larry Serflaten" <serflaten@usinternet.com> wrote:
    >>
    >>To change a variable, select View/Other Windows/Command Window from
    >>the IDE menu, then enter 'immed' after the prompt in the command window.
    >>You can then issue commands from the current development language by
    >>typing in the command and pressing Enter. (Help says '>' is needed ahead

    >of
    >>the command, I found otherwise using VB.Net.)
    >>

    >
    >The Command and Immediate functionality share the same window. The '>' character
    >appears automatically in front of any line under Command mode, but does

    not
    >appear (and is not used) in Immediate mode.
    >VS commands (such as SaveAll, etc.) can only be invoked while in Command
    >mode.
    >
    >To switch from Command mode to Immediate mode: immed[enter]
    >
    >To switch from Immediate mode to Command mode: >Cmd[enter]
    >
    >-Rob



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