how much Difference between coding in VB6 & VB.Net.

The differnces are significant, but you will adapt. The real problem is the
"missing de{*filter*}". MS put in the cheap script de{*filter*}, and now you cannot
edit your code while it runs. Put THAT together with the need to learn new
classes for everything and new GUI tequniques for aeverything, and you lose
at least an order of magnitude in productivity. Since the working de{*filter*}
is atlease another year and a half out, you productivity will always be
significantly lower.

Is edit and continue really all that useful?  I can't think of a time in any
version of VB where I've actually used that feature.  And, by the way, there
is a "working de{*filter*}" in VB.NET.  Every single de{*filter*}  feature that
appeared in previous versions of VB (minus true edit and contine) appears in
VB.NET, and these features, I believe, are FAR more useful.  Locals window,
breakpoints, watches...things that really matter.  What is all this fuss
about a "missing de{*filter*}"?
_______________________________________
Karl L. Houseknecht, MCSE+I, MCSD, MCDBA

I haven't heard of a serious programmer that wasn't complaining about the
lack of edit&compile&continue.

Armin

Since my primary development is still in VB6, I use edit & continue probably
on a daily basis.

We have several utilities here that process large volumes of external data.
We usually run utilities from within the IDE, so that whenever one of the
external sources finds a new way to hose a file at the 75% mark, we can
adapt the code to deal with the new problem, and continue on our merry way
without having to start over and waste hours of processing time.

--
Toby Herring
Software Architects, Inc.
MCDBA, MCSD

To the contrary, many serious programmers that have discussed this issue on
many other mailing lists and newsgroups would disagree with this statement.
Count me as one... I am glad it is gone, and hope that MS sticks to their
guns and leaves it out.  I have long wished for a mechanism to turn this
feature off in VB, forcing my development team to think and plan out their
code before they start typing.

The developers I have worked with that rely on E&C are usually the same that
write monolithic routines.  Instead of creating thoughtful, pre-designed
algorithms that are self-contained in well-designed functions, they like to
throw everything but the kitchen sink into a sub, creating a 300 line
monster that is impossible to track.  They rely on E&C to find the anomalies
trapped in a 13-level nexted If statement that deserve to be broken into at
least 10 different methods, and typically several different classes.

And the argument for productivity?  Ever made several infremental changes in
the IDE and WHAM!  You get a dialog box telling you that an error
occurred,and the VB IDE goes away (as do all of your changes, since E&C does
not allow you to Edit, SAVE, then continue).  So, you not only have to spend
the time stopping IIS and probably rebooting, but you then have to recode
the changes you made and try to remember to make them all again.

Frankly, I prefer being forced to think out how errors are chained and the
effect an exception will have on its caller.  I'd rather have error logging
with a capable error handling framework to ensure the system acts
appropriately.

--
Kirk Allen Evans
http://www.xmlandasp.net
Author, "XML And ASP.NET", New Riders Publishing
http://www.amazon.com/exec/obidos/ASIN/073571200X

Then I would say you have training issues with your staff.  Don't blame the
tool.

Eliminating any tool, no matter how obscure or infrequently used, is
absolute foolishness.  That's almost as bad as throwing away a reference
book or textbook!

Besides, you shouldn't be so closed minded and arrogant.  Not every
developer in the world is in the exact same situation you're in.  And even
if we were, I guarantee you still don't have _all_ the answers.

--
Toby Herring
Software Architects, Inc.
MCDBA, MCSD

You assume that they don't make any faults. Of course, planning has the
highest priority. But in practice programming mistakes will still be made.
It can't be excluded to 100%

Bad programming practice is the last thing, I'd ever support. IMO,
encouraging the correct application structure and enabling E&C do not
exclude each other.

That's nothing that happened to me so far in a noticable extent. It might
already have happend but I can't remember.

That's not an argument against E&C itself. Performing major changes in pause
mode is simply not the correct usage of E&C.

ACK.
Why ACK? Because the one doesn't exclude the other. Let's have a look at the
following case:

Like many of the processes in my application, there's a bigger database
batch process. Reading/writing thousands of records and so on. I planned
everything very well, everything went the way you would have done it. After
five hours, about 7 seconds before the end of the whole process is reached,
a runtime error occurs. BTW, I'm talking about the testing phase of the
product. I have a look at the error line and can see that I wrote the wrong
variable name (of course, Option explicit and option strict is on - but
that's not discussable anyway). This shouldn't happen but it will always
happen as long as human beings will write applications. Now, there are two
scenarios: I use VB6 or VB.Net. In VB6, I can correct the error, continue,
wait til the end, quit the application the usual way and save my changes.
In VB.Net, I stop the application, correct my fault and, again, wait five
hours. In short: Not very productive.

Of course, one must not have made this mistake - but that's only theory.
Again, I agree that E&C is nothing to replace a well planned application
from the concept down to the single line, but it's an emergency method that
increases productivity a lot.

The point is what E&C is considered as: As an emergency exit or as a method
of programming. The answer should be clear, so it depends on the quality of
your programmers how often it will be necessary to use E&C. In most cases,
it's useful, and I miss it a LOT in VB.Net.

Your attitude is like saying: We have traffic lights so we don't need an
ambulance. In addition, we don't want an ambulance because they could be
involved in an accident.

Armin

Thanks, Kirk.  It was a bad feature to start with.  Good riddance.

At any rate, the real point was that there IS a working de{*filter*} in VB.NET
and it works every bit as good as the previous versions'.

You are completely wrong... I work in a large team environment on a modular
application consisting of about 150 dll's. It is a highly stable and usefull
product, however there are still bugs. Our developers are top-notch, but
sometimes you make the wrong logic choice- or guess) ( not all components
and classes are 100% documented.) Out entire team of senior VB developers
use this extensively.

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
VB6 Add-Ins  that work with controls on the form, or Word macros, you know
what I mean.

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 cde 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 code
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 - or never learned how to use it
properly.
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 I put in i = i/0 and I meant to type i =
i/10.

Hi Mehdi,

The answer to your question is there is an enormous amount that is
different between vb6 and vb7 however im not going to attempt to begin
to explain all the differences because A: Im no expert, and B: just
from what i lknow theres too much to tell you.

You'll need to do some reading of your own. I think your best bet will
be to do some reading on dot net before you begin to look at vb6 vrs
vb7 syntax.

The language has changed (all for the better) but more importantly so
has the underlying platform so start at the beginning with the CLR and
Framework class library before OOPing into VB.NET because in my mind
its what VB.net now sits on thats the most important difference of
all.

As for the other discussion re: the dev tools, i have to agree its a
shame not to have e&c, especially for asp.net, man o man would that
save me some time ;0, but ive got to give a huge thumbs up to
Background compiliation. Now thats a {*filter*}y great feature!!

Well done Microsoft! :)

HTH

Micheal

I agree Joe.
It's a bit like when all the GUI tools arrived in SQL 7. Those that
thought it made us more productive were slammed as not knowing how to
program T-SQL. Remember we do this to solve business problems first,
not to prove to others that we can code to the highest level of
technical complexity.

Microsoft should have given us both options.

I see your point, but respectfully disagree.  Certain tools lend towards bad
programming practices, E&C being the most notable.  Wizard-based development
certainly follows in its footsteps.

Ha ha... so you obviously like Edit and Continue (E&C), then?  And why would
you presume me arrogant?  Because I made a compelling argument against
something you are emotionally attached to?

Instead of lamenting about the loss of E&C, try thinking about entertaining
new development and testing procedures and ideas.  For instance, take a look
at NUnit (http://www.nunit.org/).  This is a completely new concept to most
VB programmers, but has been available to Java programmers for some time.
The original concept (JUnit) was developed by some of the greatest minds in
the industry (Erich Gamma was the lead author for the Gang of Four book,
"Design Patterns").  It flies int he face of how VB programmers have
traditionally programmed (by virtue of the VB IDE), and for the good.

This is one of the most exciting parts about .NET:  nobody is limited to
their own sandbox anymore.  You can mix and match code, ideas,
methodologies, and approaches as well.

Instead of thinking about debugging and developing in the limited frame of
mind that we have been afforded since VB 3, think about how others are
approaching the same issues in software development.  Everyone has bugs in
their software, and everyone has to find them.  We shoudl adapt how we go
about finding bugs.  We should adapt how we develop software as a whole.
Try reading Martin Fowler's book "Refactoring" for some insight as to how
you should adapt your code when you find bugs or limitations in exisitng
code.  Often your changes are not merely syntactical, they are structural.
Structural changes often should be considered within a larger scope, one
that E&C would not support.  The types of changes that Fowler recommends
would cause restarts in E&C.

If you try to edit a variable in a recursive loop, you have to recompile
because that variable has already been scoped.  You can't change a parameter
list during E&C, and you cannot change a method's return type or value once
set.  You cannot declare new classes and add methods to them within E&C, and
you cannot move static methods to member methods and vice-versa.  All of
these situations will cause a recompile, in which case E&C is a wash anyway
because you have to tear down the current debugging session to commit the
changes.

I concede that E&C can be a useful feature and can enhance productivity.
But this, in no way, negates the fact that E&C lends itself toward ad-hoc
and unstructured programming.  It is entirely too enticing to make
significantly more than incremental changes in your code during debugging.
These types of changes should be made within a smaller, contained test unit
instead of within the scope of an entire system.

 > Not every

I am not sure what you mean by that, but it sounds emotionally charged.
Sorry if I offended you somehow, but programming is much more than throwing
a bunch of executable lines together and crossing your fingers.  It is our
job to learn about, understand, and follow the best practices set forth by
others in the industry.  Structured programming is not a new concept, just
one that is easily ignored.

I am pretty proud of the amount of reading I have done on learning about
programming, and I often think that I am just a beginner when I think about
the enormous amount of stuff I want to learn about.  I certainly don't think
I am in the same league as people like Meilir Page-Jones, Steve McConnell,
Don Box, Grady Booch, Jim Rumbaugh, Erich Gamma, or Martin Fowler.  However,
I certainly do respect their opinions, and learn from them as often as I
can.

And, before someone tries to twist my words and say that any single one of
these people ever said "Edit and Continue is bad", don't bother, because
none of these programmers ever said "E&C is a good thing", either.  What
each of them does advocate is pre-planned, structred programming in
discrete, easily debuggable and reusable routines. Each offers a different
approach, but it boils down to the same thing:  you should be able to debug
a single routine with a test harness prior to assembling that routine into a
larger structure (your system).

Sounds like emotion is getting hold of you before you finish typing.  I have
no idea how to perform open-heart surgery, design or implement robotics,
nothing about Chinese philosophy, and I couldn't offer much about the
migration path of swallow (Western or European).  No, I don't have all the
answers, and never claimed to in my post.  However, I do assert that E&C
lends itself toward bad programming practices, and will defend that point to
anyone asserting the contrary.

--
Kirk Allen Evans
http://www.xmlandasp.net
Author, "XML And ASP.NET", New Riders Publishing
http://www.amazon.com/exec/obidos/ASIN/073571200X