TECH TIP: Break - Edit - Continue alternatives

[Larry Serflaten]

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

[Rob Teixeira]

"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

[Phil Weber]

> 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

[Larry Serflaten]

"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

[Larry Serflaten]

"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

[Rob Teixeira]

"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

[Gregor R. Peisker]

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

[Cali LaFollett]

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

[Kathleen Dollard]

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

[Richard Curzon]

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.

[Richard Curzon]

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

[Mark Hurd]

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

[Phil Weber]

> 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

[Mark Hurd]

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

[Jeff Pipes]

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