I would agree that VB6 is a good place to START,
No. It's NOT a good place to start. May as well suggest people start with QuickBasic. Seems reasonable at first, until you realize that VB6 is a commercial product, the Learning Edition cannot compile programs and is all but useless for any kind of development, and you can either get FreeBASIC or VB.NET for free, not to mention of course C# Express and python and so forth.
VIsual Basic 6 is from 1998. Unless you want your programs to look 13 years old, you'll need to use all sort of third-party libraries to work around the limitations of Visual Basic 6 that prevent it from doing perfectly reasonable things that more modern/updated languages have built in- such as the aforementioned 32-bit image support. Once you start doing that you realize why Microsoft Abandoned COM. And if you ever have to write a COM component in C++ (specifically, without ATL) then you won't be saying that "lower level" languages aren't bloated. It takes reams of code to create a standard COM object that takes a few lines in VB6, with the exception that you cannot use about 20 percent of the most useful Automation types, cannot implement any standard COM interface (ever have to implement IEnumVariant? Do you REALLY think that directly modifying the Vtable in memory is something that is perfect for beginners? Having to create code modules that contain sets of pointers that directly manipulate memory just to work around the fact that VB6 doesn't let you implement an interface that happens to have a method that is named "Next" is absolutely stupid, particularly since any modern language let's you get the same functionality that implementing IEnumVariant would give you with a single statement- C#'s "yield return" and Python's... well, I'm not sure what the python statement is, but it does have iterative methods. it also supports lambda expressions, iterators, delegates, and functional programming; so do C#, VB.NET, F#, Java (at least in it's latest incarnations), Scala, Haskell and even (although I'm not sure) FreeBASIC to some extent. VB6 doesn't because- as I said- it's 13 years old. If you want to learn relevant programming techniques for the here and now you need a language that has been kept up to date with here and now. using a 13 year old language- particularly one that is a abandoned commercial product (which doesn't make it free, but makes it throwing money down a hole even to buy it second hand) when you have so many free and significantly better supported and modern languages available isn't being industrious, it's being a hard-headed buffoon.
That doesn't mean that you can't learn from it though.
All you can learn from it, is history; and maybe about the ridiculous three-tier architecture that was so popular... 13 years ago- but isn't now.
I would not try .NET though because your are just adding more layers to an already huge infrastructure. I know BC is going to say how great .NET is, but I stick to lower level languages. I don't like the bloat.
I'm not going to say "how great .NET is" I'm going to say how wrong you are in your various assumptions. I'll go through them one by one.
-.NET adds more layers to an already huge infrastructure
What infrastructure? *censored* are you even talking about? How is .NET's class library any different from Java's or Python Modules? It's not, except in your mind. Additionally, having a good class library is something people seem to underrate far too often. This is clear because you seem to be championing VB6, whose basic functionality is to any modern languages functionality as a Lungfish brain is to a human brain. That is, possibly worth study but otherwise useless.
-but I stick to lower level languages. I don't like the bloat.
First off, Visual Basic 6 isn't a "lower level language" neither is python. If you believe that you are deluding yourself. C++ is, but again if you had ever written a non-trivial windows application or COM library in C++ you would know it either turns out bloated or full of template classes (a 'la ATL).
Even though VB6 isn't a lower level language, the bloat argument doesn't apply; half of the functionality of my VB6 programs comes from separate ActiveX controls and reams of separate code- the
VB6 code required to show a "Right-click context menu" for a file is over 64K, and that still isn't all that's required- there are separate class modules, Type Library References, and the like that that code still requires to work. And a good portion of the interfaces in ISHF_EXT and olelib2 (which you should be familiar with if you call yourself a VB6 programmer) which would otherwise have relatively sane implementations, need the creation of separate modules with reams of code to essentially bit-bash the Vtable of a simulated COM object just so you can properly "implement" an interface whose method name happens to correspond with a reserved word. And Heaven forbid you try to implement an interface with an unsupported type- welcome to vague city. GO ahead, try to make your own implementation of IDispatchEx. At least more modern languages have well thought out support for objects and interfaces. VB6 is just using the same old rusty sign that was stapled onto VB4, and at that point it was so weighed down by webclasses, Interface (but not implementation) inheritance, and the fact that you had to manually bash the bits to get otherwise bog-standard (if not badly designed) Interfaces like IEnumVariant working properly, it was no wonder they decided to scrap the entire thing and start anew. It was pretty obvious this was going to happen when you realize that all that VB6 introduced over VB5 was a few functions and the fact that you can return UDT's from functions. Clearly they had already started work on what was to become .NET.
The only semi-reasonable argument against .NET is that it needs to be installed on the client machine and it is big. of course that falls apart since most modern Windows OS's have a version installed by default and even those that don't are almost certainly not "clean" installs of the OS and have probably picked up the framework via necessity of other applications being installed; That and the fact that the Java VM never seems to get the same amount of flak make me wonder if those pushing these arguments aren't merely pushing them through there own Anti .NET tunnel-vision, without regard for the fact that their arguments are so general they apply to far more then the target they are aiming at.
What are you talking about? Every VB6 app that I made runs fine on XP without any changes.
That's because you are making Standard EXE's and not using any custom controls or ActiveX DLLs written by you or anybody else.
Once you start using custom controls- and if you want a application that looks even semi-modern, you will need to- Almost NONE of BCSearch is using the default controls.
http://bc-programming.com/images/bcsearch.png-The menu and toolbar is a VBAccelerator commandbar control. The interface to which is so complicated that I ended up simply writing a class that populates it from a XML file.
This COmmandBar is awesome, since it adds two things that VB6 should have by default:
-proper support form manipulating Menus as if they were heirarchal... (because, you know, they are)
Specifically, There is no way to programmatically create a submenu without resorting to the Menu API calls, and then you no longer have Menu Objects to line up with those new MenuItems so you have to subclass the form entirely to handle the various Menu Commands. Then you have to find out a way to map a menuID to a actual Menu Object so you can find out if a menu already has a handler that would be invoked if you were to call the Default Window Procedure or whether it is one of the menus you created using the Menuing API, and then you give up and merely handle all the menu commands in the Subclassed Windows Procedure, which pretty much bars you from ever using the debugging tools within that handler, unless you use ANOTHER third party library to handle the subclassing of the window, (How is that for "adding more layers"?), And by that point your code is no longer VB6 code, it's C/C++ code win VB clothing- I mean, handling the Window procedure and using a giant Select case to determine the window message? .NET actually allows you to manage heirarchal menus as if they were- (get this) a heirarchy of menus! No more fecking stupid Control arrays. .NET is hardly alone. Java has this as well. And while I am far less familiar with it I have no doubt Python does as well in the various Win32 modules. Once you use AddressOf in VB6 to subclass a window, you've turned your application into a rube goldberg device. Any error or crash inside the Window procedure and the entire application dissapears. In the middle of debugging? Hope you saved since VB6 crashes without warning as well. If you want to write "modern" code in VB6 you have to resort to subclassing nearly everything and writing a window procedure. If you want to write a window procedure, you should use C/C++ (or .NET, did I mention that it has built-in support for subclassing, merely as an Event on the Windows Form? Same with WPF Windows, I believe)
-Listviews are VBAccelerator Listviews. Because the default Common Controls 5 & 6 Listviews are awful. Anybody who says otherwise hasn't used them very much. The Version 5 Common controls suck because they are version 5,(1996) and the version 6 Common Controls suck because they aren't even the Windows Common controls, they are entirely unique controls, so you cannot do any "fancy" subclassing stuff on them even if you know exactly what you are doing, since the comctl32 library isn't involved at all.
-I had to write an entire File Library to work around the fact that VB6's built-in support for file/folder manipulation is about as sophisticated as the BASICA's, which is to say they are almost identical. That's some good progress there. The FileSystemObject hardly makes up for that since it only supports text files and was pretty much banged out in an hour. That, and it's for use with Scripting languages. Quick, what's the VB6 function to get the Icon of a file? That was a trick question. There isn't one. SHGetFileInfo() is simple enough with practice but unless you happen to have a ImageList that supports 32-bit icons you'll just end up with an ugly mess of black shadowy icons. Neither of the ImageList Controls shipped with VB6 supported 32-bit icons or bitmaps.
-Requires a Manifest file (either as Search.exe.manifest or embedded as Resource 24, the latter of which requires the freaking Resource compiler from the SDK) in order to draw properly with uxthemes in XP or using the Vista/7 styles; without it that image uses standard buttons since Windows links the executable to Common Controls version 5.0; this also means that almost half your application could fall apart thanks to your objects suddenly being an older version but you working with them as if they were newer.
Which I might point out are ridiculous to try working with in VB6. Go ahead. try it. If you enjoy messing around with hbitmaps and creating your own Imagelist handles, then it's a blast, but trust me when I say that wears off. None of the "standard" controls included with VB6 let you use a Alpha channel, in fact with most of them even the support for transparency seems to be an afterthought. The fact that the ImageList has to be a control with those severely limits it's usefulness (thus why I used a separate class of my own writing- and now one from VBAccelerator- so that I can keep it around in a singleton class rather then have a stupid resource only form lying around, something which I would have expected to abandon after I stopped using Visual Basic version 2.0, but apparently that wasn't the case.
And that doesn't even touch on the fact that VB6 is entirely locked to the windows platform. (Or wine); at least .NET programs can be run with Mono. It's still painful, but at least it's Possible to run it natively on that platform. And Of course Java, Python, perl, etc have absolutely no problems whatsoever, and are even installed by default with most distributions.
Recommending anybody learn VB6 in 2011 is like recommending they jump into a swimming pool filled with double-edged razor blades. It's stupid and anybody following said suggestion is either stupid themselves or too naive to understand why it's stupid.
