On-the-fly debugging is missing from  Visual Basic. That means that when you
code encounters an error or you break the code with a stop point, you can
edit the code and continue running your application.
MS will tell you that the de{*filter*} is improved - it is not true!, it has
been dumbed down to the level of VC++ or JAVA. The closest comparison is to
the VBScript de{*filter*}. Now while you can edit the code while it runs, you
cannot have your changes count until you:

1-Stop execution
2-Rerun your application
3-Get to the point it failed in the first place
4-Hope you guessed correctly at the fix.
This is a dog slow way to code, a typical cycle on my PIII-750 is ~30 secs
for a tiny program.

I can give numerous examples wher you do need On-the-fly debugging

1) You have a recordset with column names, but you may not be sure wich
names are valid. You can find out which ones are valid when your code stops,
by using a for each loop in the immediate window (Intellisense no longer
works there either) and find the correct field name; modify your cde and
continue.

2) You are working with an object for which you have little experience you
need to make educated guesses about which methods and properties to use. You
determine the correct sequence empirically. I call this dissection, other
would call it hacking. If you ever worked with XMLDocument object or written
Add-Ins to work with controls on a VB Form, you know what I mean.

We now know why VC++ programmers always looked at down at us VB guys and
said: "VB is a good prototyping language." Now we have to prototype our
difficult code in VB6.

3) You have a logic path giving incorrect results. You stop and watch it and
realize you needed a 'If Not x' instead of 'If x'; modify your code and
continue.

4)You have a large application where test cases may be time consuming to set
up. You step through the code to determine the failure point. You find it,
perhaps an Insert statement with poor syntax. You get past that point and
find another just like it. However, because you had to stop at the 1st point
of failure your test case is ruined. ( You did not write the code, so the
changes were not part of a transaction). Since you can't 'modify your cde
and continue' you are screwed, blued, and tattooed.

5) You are rendering a web page (perhaps with a webclass), but your HTML
output has a  glitch preventing proper display in a browser. You stop the
code, change it, perform a refresh in ther browser and continue until it is
correct.

6) The compiler accepts the code you entered, but chokes when it executes.
You may not know the correct line. You could try many variations until you
get it right. But not in .NET, it will take alot longer, even on a 12 line
application.

7) You are writing logic to resize a form or Usercontrol which arranges sub
controls on the object. You can change the code until you get it just right.
Now 'just right' will be 'whatever is good enough to work' etc, etc,
etc,....

I could go on and on. If you are a recent convert to VB you probably never
knew how powerful the de{*filter*} WAS. You have no prior experience, ergo you
never expected it and maybe never found it. To be honest, until I started
talking to other developers with experience in other tools, I thought
everybody had on-the-fly debugging.  After all, it is the year 2001.

However as I talk to people who have used the tool for several years, I am
finding they are as incredulous as I am the the de{*filter*} so poor.  I don't
find the currect de{*filter*} any more valuable than the VB script de{*filter*} in
Visual Interdev. And don't tell me about how now I can look at registers and
such, that is not important to a VB programmer. We may not even know what it
means. But we do know that when we typed:  i = i/0 and meant to type i =
i/10, we could correct our error in VB1-6

If you care about this feature you must let MS know!!! Post your answers and
send email to the MSFTees on this News Group.

Can I hear an "Amen"!!!

Well put Joe!!! Up untill recently, I had stayed away from the .NET band
wagon. I have even written a few slams to it, inluding one to VSM (VBPJ
Renamed). But, being the {*filter*} that I am, I decided that I better know what
I am slamming before I slam it too much.

I went ahead set aside a seperate partition for it and installed Beta 2
after it cam in the latest VSM. Bought some books on the subject and set out
on the VB.NET journey. While I definitely appreciate the vast improvements
to VB (there are a few I am still torked about but that's another issue) I
am utterly appauled that MS ripped out Edit and Continue.

I know that EC relied on P-Code in VB 1-6. I also know that they could have
found a way to make it work IN THIS RELEASE since IL is still interpretted
and has to be JITted!!!!!!!!! I do not see why they could have not figured
out a way to incorporate JITing into the Debugging or vice versa.

I am now finding myself at debug time editing code and trying out the
results of those changes only to get that {*filter*} little "Would you like to
recompile?" dialog box. Old habits are hard to break!!!!!!! With sooooo many
changes to VB and the addition of the Framework, there is going to be a
great need for EC. Heck, I look at it as one an awsome learning tool too!
What better way to try out different things than right then and there on the
spot?

I hope you guys/gals/marketers/developers/managers at Microsoft are truely
reading this newsgroup!! EC is one thing that really set VB appart from the
rest of the languages and IDEs out there. I think you are making a big
mistake by leaving it out. I also think that a majority of the VB developers
out there would agree!

--
Regards,
Cal

I am in complete agreement with Cali and Joe.  The ability to edit on the
fly was THE killer feature that five years ago made VB my language of choice
of C++.  And while I am a very strong supporter of .NET and am delighted by
the many improvements, the ability to edit and continue is SORELY missed.

I've been baffled that MSFT has had so little to say on the issue.  This is
IMHO an essential part of VB-ness.  Dare we hope that the loss of edit and
compile was merely deferred to meet a ship date and that it will be
reinstated at some time in the not so distant future?

Regards,
Jay Cincotta

Yea, I wonder if we ought not pull this one back out to the main thread so
that we can get more people to reply to it. There is power in numbers! ;-)
--
Regards,
Cal

The thing is, it basically makes it quicker to debug the little niggly
errors..
Don't know about anyone else, but it seems a crime to take out a useful but
old feature like that and give us nothing better in return...

Exactly!!! ;-)

Cal