It was the M$ VB6 to .NET Upgradde Assesment Tool
http://www.microsoft.com/downloads/d...displaylang=en
Printable View
It was the M$ VB6 to .NET Upgradde Assesment Tool
http://www.microsoft.com/downloads/d...displaylang=en
Thanks Pasvorto.Quote:
Originally Posted by Pasvorto
I agree but the problem often is that senior management wouldn't listen - they simply mandate the "latest and greatest" so lots of developers won't even have a choice [unfortunately].Quote:
Originally Posted by bgmacaw
If we are talking about organizational improvements in .NET, the one I like the most is #Region. That makes it sooooo simple to shunt things out of the way temporarily.
What I meant about organization in VB6 was that there was nothing in VB6 that was keeping you from putting a few public variables in each of several modules. That could easily get a bit messy, especially if you get into name conflicts, and have to figure out where your conflict is coming from. More of a nuisance than anything else, but a nuisance is rather the point. If you have enough minor nuisances, you spend too much time doing the housekeeping. The purpose behind OO was primarily organization. Those other nice things, like polymorphism, inheritance, etc. are all very well and good, but the key to objects is encapsulating data and the methods that use the data. If you use only that feature of OO, you are certainly not using it all, but you will avoid some of the pitfalls in an aggressive OO design (like long, unmanageable inheritance trees).
Of course, you could organize a VB6 module in the same way, with private (module scope) variables, and public methods that worked on them. You could also have a single module where ALL public variables resided, which would keep them tidily organized in one place. This looks alot like the first steps into OO, but it requires discipline to organize a VB6 project that way, while it is much easier in .NET.....until we start getting into partial implementations of classes, then we can have a single class scattered across any number of files, which strikes me as being a recipe for confusion.
Partial Classes should only be used where part of the class is automatically generated code (e.g. from a wizard or codegen tool) - according to my VB2008 coding standards anyway.
You substituting new language feature with "organizing" - they are not the same.Quote:
Originally Posted by Shaggy Hiker
For me "organizing" means that everything is in place and is very easy to access
For instance, I hate new editor for one simple reason - it does not have "single procedure view" functionality like it was in pre.dot.net.
Here is what you do - open your code editor, go to any procedure and hit Ctrl+End... You know what's going to happen next - if you have large module you'll be taken at the very end of it.
Whould you call that good "organizational improvements"? I wouldn't.
To make the point:
anything you use (super nova or very old) is just a tool and YOU have to have organizational skills in order to use it properly.
If you don't have it then there is nothingin the world that would help you - Dot.Net or not it doesn't really matter.
Best regards.
AH! So now we get to the root of RB's issues... it's NOT with the language... but the IDE.
Ctrl+End - has always taken me to the end of the code... but I don't like the single proc view anyways. Ctrl+DownArrow would take me to the next proc in the code - I've found that to be helpful.... doesn't work in VS... wished it did. But I'm not going to hold a grudge against VB.NET for a failing of the IDE.
-tg
FWIT: #Region is also an IDE feature, not a language one.
How could it not be? It's a dinosaur or perhaps a Mammon if you will... Slow, bulky... :mad:Quote:
Originally Posted by techgnome
... and #Region is not an IDE feature ... ;)
I agree with that last point. I just think there are more tools. While Ctrl+End will do that for any file that I am aware of, being a Windows standard, you also have a little button that will take you right back to the very line you were at. Thus if you bounce to a different module by looking for the definition of a function, you can go right back when you want to.Quote:
Originally Posted by RhinoBull
I fail to see how #Region, which is not a language feature, but an IDE feature (no MSIL code is generated), could be considered anything other than an organizational tool. What other purpose could it serve?