Slashdot Mirror
Visual Basic 2005 Jumpstart
Graeme Williams writes "The tag line for Visual Basic Jumpstart is, 'Make Your Move Now from VB 6 to VB 2005', but the book also includes introductory and summary material rather than staying focused on VB 6 users. The book has a few good examples and some useful information about Visual Basic 2005, but the information, including links to the Internet, doesn't seem complete or up-to-date. This book isn't the help you need." Read the rest of Graeme's review.
Visual Basic 2005 Jumpstart
author
Wei-Meng Lee
pages
xiv + 197
publisher
O'Reilly Media
rating
5
reviewer
Graeme Williams
ISBN
0-596-10071-X
summary
A useful but flawed snapshot of Visual Basic 2005 without a clear audience
My current (small) applications are in Access and Visual Basic for Applications rather than VB 6, but with that caveat I'm part of the audience for this book, since I'm actively considering moving them to Visual Basic 2005. I want to like this book more than I do. Part of my confusion is that all of the chapters are useful, but I don't think they're useful to the same people.
I have no idea who the audience is for Chapter 2, "Programming with Visual Basic". Some of the information is useful and relevant, with specifics on differences between VB6 and VB2005, but some of it just seems plain silly: "Just as in VB 6, in VB 2005, you make decisions using the If-Then-Else construct". The wording is sometimes odd, too. The fact that parentheses in function calls are now mandatory in VB 2005 is explained backwards: "VB 6 Tip: In VB 6, you can call the PrintMessage subroutine without using parentheses to enclose the parameter list." The chapter could have been collapsed into a very clear and not very large table giving the differences between VB 6 and VB 2005.
In VB 2005, Microsoft has introduced a new bag of functions under the My. namespace. It's not a very big bag – it feels like the product manager wrote down the first four or five functions he thought of. For example, My.Computer.Network contains just five elements: IsAvailable, DownloadFile, UploadFile, Ping, and the NetworkAvailabilityChanged event. Jumpstart describes it as " ... one of the most useful and unique additions to VB 2005 ... The aim of the My namespace is to provide direct access to commonly used libraries in the .NET framework that were previously difficult to access." I'm sorry, that just sounds too much like a press release.
If you're really interested in the status of a network interface, for example, you need to look in the 30+ classes in the System.Net.NetworkInformation namespace. But this is not included in the list of "some other useful namespaces in the .NET framework" (p61). Also, Example 4-3 (p117) uses the System.Net.HttpWebRequest and System.Net.HttpWebResponse classes to download an image, not any of the classes mentioned in Chapter 3.
On the face of it, Chapter 3, "Putting Object-Oriented Programming to Work", provides a very clear and thorough introduction to the object-oriented programming constructs in VB 2005. Unfortunately, it's not complete. Microsoft has a summary of "Object-Oriented Programming for Visual Basic 6.0 Users" which points out that the Binary Compatibility option from VB6 is no longer supported in VB 2005, but this is not mentioned in Jumpstart.
If you're moving from VB6 to VB2005, you're also moving to NET 2.0, but the book has only the most cursory introduction to NET 2.0. Part of the problem is that the book needs to be either more or less reliant on online information. If it was less reliant on online information, it would be more useful as a stand-alone resource. If it was more thoroughly linked to the estimable resources at Microsoft.com, it would be more complete and up-to-date.
Jumpstart mentions two MSDN Help Topics: "Programming Element Support Changes Summary" and "Help for Visual Basic 6.0 Users". The former is very useful, perhaps more useful than found in this book, although it's organized in MSDN's one fact per page style. The latter can only be found via Google, since it is now part of MSDN2, the "new MSDN" for Visual Studio 2005 and SQL Server 2005. MSDN2 is not mentioned in the book, nor is VBRun, the Visual Basic 6.0 Resource Center, which has a boatload of information on moving to VB 2005.
The database application in Chapter 4, "Developing a Windows Application" is useful and clearly presented. It's a nice example of the new SplitContainer control. But it's no better than examples in other introductions to Visual Basic, and it's a little hard to see how it's suited to the stated purpose of this book – of introducing developers with an existing Visual Basic 6 code base to Visual Basic 2005.
The term "jumpstart" cuts both ways. The goal of the book is to give VB6 programmers a rapid introduction to Visual Basic 2005. But the book itself was published rapidly – before Visual Basic 2005 was released – and some of that speed shows. On page 126, Jumpstart instructs you how to configure Windows XP to run IIS, but on page 139 points out that this isn't possible in XP Home.
Chapter 5, "Building Web Applications", explains that Visual Studio includes its own web server, so you don't need to run IIS, but the fact that Visual Basic 2005 Express doesn't include this feature is mentioned only in the preface (page xi). To provide IIS, you need either Windows XP Professional, or Visual Studio Standard or above, or Visual Web Developer 2005 Express. Wouldn't it make sense to explain the various combinations of operating systems and Visual Studio editions in one place, at the beginning of the chapter where they're relevant?
I'm not an ASP programmer, but I feel as though the 35 pages devoted to ASP probably aren't enough to give the topic a decent introduction, which perhaps deserves a separate book. For example, authentication is covered in just three short paragraphs. The 35 pages could have been devoted to something more central to the topic, such as more details on .NET 2.0. Obviously, there are other books on .NET 2.0, but while you can use Visual Basic 2005 without ASP, you can't use it without .NET 2.0.
If we take the book's tagline seriously, Chapter 6, "Moving from VB 6 to to VB 2005", should be the core of book, but it seems like more of an afterthought. Much of the content is from Artinsoft. Rather than reading about about it third-hand in this book, or second-hand on MSDN, I recommend you go to the the Artinsoft web site, where they have plenty of information for download.
It's hard to put a numerical rating on a book like this, which doesn't seem focused or particularly thorough, but still contains a lot of useful information. The book could have been better if it had been linked more systematically to Microsoft's online resources. It might have seemed better if the audience had been clearer. A rating of 5 ("Neither terrible nor terribly good") seems about right. By all means buy the book if you think it will be worth the money to have the information and examples in book form. Just don't expect too much."
You can purchase Visual Basic 2005 Jumpstart from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page
My current (small) applications are in Access and Visual Basic for Applications rather than VB 6, but with that caveat I'm part of the audience for this book, since I'm actively considering moving them to Visual Basic 2005. I want to like this book more than I do. Part of my confusion is that all of the chapters are useful, but I don't think they're useful to the same people.
I have no idea who the audience is for Chapter 2, "Programming with Visual Basic". Some of the information is useful and relevant, with specifics on differences between VB6 and VB2005, but some of it just seems plain silly: "Just as in VB 6, in VB 2005, you make decisions using the If-Then-Else construct". The wording is sometimes odd, too. The fact that parentheses in function calls are now mandatory in VB 2005 is explained backwards: "VB 6 Tip: In VB 6, you can call the PrintMessage subroutine without using parentheses to enclose the parameter list." The chapter could have been collapsed into a very clear and not very large table giving the differences between VB 6 and VB 2005.
In VB 2005, Microsoft has introduced a new bag of functions under the My. namespace. It's not a very big bag – it feels like the product manager wrote down the first four or five functions he thought of. For example, My.Computer.Network contains just five elements: IsAvailable, DownloadFile, UploadFile, Ping, and the NetworkAvailabilityChanged event. Jumpstart describes it as " ... one of the most useful and unique additions to VB 2005 ... The aim of the My namespace is to provide direct access to commonly used libraries in the .NET framework that were previously difficult to access." I'm sorry, that just sounds too much like a press release.
If you're really interested in the status of a network interface, for example, you need to look in the 30+ classes in the System.Net.NetworkInformation namespace. But this is not included in the list of "some other useful namespaces in the .NET framework" (p61). Also, Example 4-3 (p117) uses the System.Net.HttpWebRequest and System.Net.HttpWebResponse classes to download an image, not any of the classes mentioned in Chapter 3.
On the face of it, Chapter 3, "Putting Object-Oriented Programming to Work", provides a very clear and thorough introduction to the object-oriented programming constructs in VB 2005. Unfortunately, it's not complete. Microsoft has a summary of "Object-Oriented Programming for Visual Basic 6.0 Users" which points out that the Binary Compatibility option from VB6 is no longer supported in VB 2005, but this is not mentioned in Jumpstart.
If you're moving from VB6 to VB2005, you're also moving to NET 2.0, but the book has only the most cursory introduction to NET 2.0. Part of the problem is that the book needs to be either more or less reliant on online information. If it was less reliant on online information, it would be more useful as a stand-alone resource. If it was more thoroughly linked to the estimable resources at Microsoft.com, it would be more complete and up-to-date.
Jumpstart mentions two MSDN Help Topics: "Programming Element Support Changes Summary" and "Help for Visual Basic 6.0 Users". The former is very useful, perhaps more useful than found in this book, although it's organized in MSDN's one fact per page style. The latter can only be found via Google, since it is now part of MSDN2, the "new MSDN" for Visual Studio 2005 and SQL Server 2005. MSDN2 is not mentioned in the book, nor is VBRun, the Visual Basic 6.0 Resource Center, which has a boatload of information on moving to VB 2005.
The database application in Chapter 4, "Developing a Windows Application" is useful and clearly presented. It's a nice example of the new SplitContainer control. But it's no better than examples in other introductions to Visual Basic, and it's a little hard to see how it's suited to the stated purpose of this book – of introducing developers with an existing Visual Basic 6 code base to Visual Basic 2005.
The term "jumpstart" cuts both ways. The goal of the book is to give VB6 programmers a rapid introduction to Visual Basic 2005. But the book itself was published rapidly – before Visual Basic 2005 was released – and some of that speed shows. On page 126, Jumpstart instructs you how to configure Windows XP to run IIS, but on page 139 points out that this isn't possible in XP Home.
Chapter 5, "Building Web Applications", explains that Visual Studio includes its own web server, so you don't need to run IIS, but the fact that Visual Basic 2005 Express doesn't include this feature is mentioned only in the preface (page xi). To provide IIS, you need either Windows XP Professional, or Visual Studio Standard or above, or Visual Web Developer 2005 Express. Wouldn't it make sense to explain the various combinations of operating systems and Visual Studio editions in one place, at the beginning of the chapter where they're relevant?
I'm not an ASP programmer, but I feel as though the 35 pages devoted to ASP probably aren't enough to give the topic a decent introduction, which perhaps deserves a separate book. For example, authentication is covered in just three short paragraphs. The 35 pages could have been devoted to something more central to the topic, such as more details on .NET 2.0. Obviously, there are other books on .NET 2.0, but while you can use Visual Basic 2005 without ASP, you can't use it without .NET 2.0.
If we take the book's tagline seriously, Chapter 6, "Moving from VB 6 to to VB 2005", should be the core of book, but it seems like more of an afterthought. Much of the content is from Artinsoft. Rather than reading about about it third-hand in this book, or second-hand on MSDN, I recommend you go to the the Artinsoft web site, where they have plenty of information for download.
It's hard to put a numerical rating on a book like this, which doesn't seem focused or particularly thorough, but still contains a lot of useful information. The book could have been better if it had been linked more systematically to Microsoft's online resources. It might have seemed better if the audience had been clearer. A rating of 5 ("Neither terrible nor terribly good") seems about right. By all means buy the book if you think it will be worth the money to have the information and examples in book form. Just don't expect too much."
You can purchase Visual Basic 2005 Jumpstart from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page
You jump "startled" me :)
VB.Net is syntactically a lot different from classic VB. If you're going to make the switch, you might as well learn C#. Then you will also be familiar with C/C++ style coding.
Ditch the Dim!
Pick a subject you learned yourself hastily, then find a publisher known for editors unfamiliar enough with your subject to accept it as gospel because the manuscript is long and *looks* intelligent.
Look up Amazon reviews of Mortier's books on 3D design applications and you'll see almost the same reviews as above.
"Made up/misattributed quote that makes me look smart. I am on
I think that the book should start off by trying to explain to me WHY I should move from VB6 to VB2005. From everything I've read, there's little reason to make the jump. I've got probably a dozen, working, mission-critical VB6 apps right now, and I just don't see the point.
I don't respond to AC's.
...because at the rate Microsoft keeps coming up with new and incompatible versions of VB, it seems a foregone conclusion that by the time you absorb the book and have Made Your Move Now from VB 6 to VB 2005, it will be time to buy VB Jumpstart 2006: Make Your Move Now from VB 2005 to 2006, and then VB Jumpstart 2007, VB Jumpstart 2008, etc.
.NET profit.
For the lucky author, it gives a new meaning to the phrase
"How to Do Nothing," kids activities, back in print!
Public Main (e EventArgs) {
Stupid Microsoft = new stupid();
Microsoft.GoBankruptIn = 100;
Microsoft.Start();
}
Public On_Bankrupt (e EventArgs) {
Linux Ubuntu = new Linux();
Ubutnu.DominatePlanet();
}
There, now maybe Linux can dominate the world.
No such thing as a migration from VB6 to .NET. VB.NET is simply .NET with a VB-like syntax. Anything at all larger than a few lines is best rewritten from the beginning.
.NET, it'll end up being a lot more effort than just writing it from scratch.
IMO, it's pointless to try to convert a VB6 program to
This is the risk you take when coding using closed tools. There's no more support for VB6, and no real migration path.
"The venerial disease of languages."
While this may not be a general concern for some developers, Microsoft has moved Visual Basic 6 out of "Mainstream Support" (as of 3/31/2005) and into "Extended Support". Extended support is set to end 3/31/2008. How does that affect you? If your application is working now, what's going to cause it to break? Well, it may not, but some companies (or individuals) have policies put in place as a CYA that you may not be able to develop using tools that are no longer supported by the vendor. It gives them someone to hold liable (read "blame") if something breaks.
r t=PN&alpha=Visual+Basic
Then again... you are using Visual Basic on a Windows platform...
(Queue the music as we wait for people to bash MS, VB, or Windows...)
Visual Basic Product Lifecycle: http://support.microsoft.com/lifecycle/search/?so
i'd do it but here i am without mod points
Put in a space before the / in your sig, otherwise rm won't work.
I love all the titles the VB authors use for their "insights" into this decrepit language. Like "VB Unleashed!" as if VB is some rabid animal, or "Hidden VB secrets" just dug up from King Tuts tomb.
I see a nice spot on my bookshelf for this book, beside my kids "Jumpstart Toddlers" CD's.
VB is the whipping boy of Microsoft. Every iteration changes the language in some crazy way. I started pre-VB, but for the VB line, I started at VB1.0. I've watched it "grow" (I perfer mutate) over the years. I now still do about 90% VB. But I have tired of the language changing every few years. I've fallen in love with Python. It is cross-platform and easier. The only thing needed is a good GUI. I prefer Qt, (which is GPL or commercial). The effort of supporting more than windows in one platform is trivial with python, which opens up the MacOSX market (and linux too.)
Even if you don't need crossplatform, Python has all that COM support and is highly integrated into the Windows OS. To me, it is worth my time to learn python because the languages changes very little. It also is 'cleaner'.
Ruby fans don't flame me. I know the two are close, but I can only recommend what I have used extensively.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
There are no crappy languages, but there are a lot of crappy programmers.
Steve's Computer Service, Hobbs, NM
VB.NET and C# are basically equals in the .NET world and both are RAD, etc. You can develop just as quickly in C# as VB.NET. However VB.NET has no benefits outside of .NET whereas C# does. If you learn C# you can switch to C or C++ or Java easily (much easier than a VB programmer switching to one of those languages). VB is just MS whereas C# has a syntax used by many other languages. Do yourself a favour and ditch VB now and learn C#.
Learn VB is like learning a language that only one village uses when they also speak another language which almost the whole world speaks.
I write in VB.NET 2005. I feel like it's all stagnant. The welcome page in the application hasn't updated since November, most code examples are referring to VB6, what little I can find on VB.NET 2005 is about the public beta, and recent posts to boards regarding the language reveals that many think the software is still in beta even though it was released about five months ago.
Clickonce deployment is one of the most exciting things I've seen in ages, but aside from a couple little exercises I wrote, I've only seen one application deploy with it. I love the idea of deploying trusted Windows apps in much the way Java is used today. Clickonce apps run in a sandbox. The Clickonce security handler needs help - if you run a program that tries to use permissions it hasn't asked declared needing, instead of prompting the user to approve the higher trust level (the behavior shown in the documentation) the Clickonce handler crashes!
Frankly, I'm tired of trying to find decent documentation. I have yet to get COM code that works - the samples on the site are pockmarked with errors. It seems like I'm almost working in a vacuum. I need a book that doesn't suck.
Why do people use it?
Because it works. It is simple. It gets the job done fast.
It works most effectively for smallish one-off projects and, I admit, there are better tools to use for anything that requires a software engineering effort, but VB fills a lot of needs.
The "sister" language, VBA, is ideal for vendors who want to provide rich, user-accessible scripting interface to their hardware or software products.
Because vbscript works with excel, word, access - learning vb gets you to work with almost every microsoft product from asp server scripting to making vb6 windows applications to client side vbscript coding to office to scripting for other apps.
It gets the job done a lot of times coz you have 1 week to process this data or 1 week to make a quick system for the local auction.
/NOD
Ready for HD DVDs? http://hd-dvd.buy-on-sale.com
What a ridiculous bunch of FUD. What machines are you using, Pentium 166 ? My machine is rather dated by today's standards, a 1 Ghz Athlon with 512mb or ram and all the
You know the 'beep' command works just as faithfully as it did, way back in the glory days of BASIC?
Yes, but better (or worse depending on how you look at it).....
"on error resume next" is still alive and kicking! w00t!
throw new NoSignatureException();
the book also includes introductory and summary material rather than staying focused on VB 6 users
Users, not developers?
Crappy programmers make crappy languages and thus we have VB.
One of those books you purchase just because you may stumble upon an explanation to a problem you're not finding in your more robust guides.
For some reason I refuse to use either spell check or the spacebar properly.
That's the perfect way to put it. . . "VB syntax is very popular in a Britney Spears kind of way."
Brilliant! It appeals to a self-taught programmer's basic instincts to feel comfortable with an English-like language. But like everything in life, it comes with trade-offs.
(my) 32k compiled app, it takes about 15-20 seconds for the libs to load up.
We've written two VB.Net applications- one about 15,000 lines and another abour 35,000 lines and the larger one even allocates a 3,000,000 long integer hash table.
On the 1GB Ram/2.7Ghz machine neither takes more than 4 seconds to come up.
On a 256MB Ram/800Mhz laptop the larger one takes 20 seconds.
Is it the machine or is it the code?
Cogito Ergo Sum
There are no crappy languages, but there are a lot of crappy programmers.
Sorry, what? There are too crappy languages. As an extreme example, let's see you code a web application in Brainfuck. It's hard to read, takes ages to write, and is a pain to set up. But it can't be the fault of the language, because there are no crappy languages, of course.
Guy asked me for a quarter for a cup of coffee. So I bit him.
Save yourself $5.23 by buying the book here: Visual Basic 2005 Jumpstart. And if you use the "secret" A9.com discount, you can save an extra 1.57%!
The problem comes when the intrepid young VB developer, flush with his previous VB success, hooks his Honda Civic up to the 18 wheel trailer and wonders why the clutch just blew out when his Honda encountered a "load". The main problem with VB is that it frequently does not scale up when the need arrisses and managers have a difficult time understanding why something that has worked fine for years begins having problems when the number of simultaneous users begins to move into the double digits. Try explaining to that same manager why that wonderful little VB application that was so fast and cheap to build suddenly needs to be scrapped because it cannot scale up. The non-technical person will have a very difficult time wrapping their brains around that problem, they usually assume that they can just "troubleshoot" and get the whole thing working for how ever many users and whatever new features they want to throw at it. When you see his eyes glaze over and he starts nodding his head and saying yeah, uh-huh, sure, and right then you know that you have reached this point.
Loved it, then hated it...
.Net... It wasn't that I was not receptive to all the really cool new OO and "advanced" capabilities (threading being a big one) it was the total lack of any "nod" toward the previous VB developers.
.Net version of VB, telling him how I was never going to switch and the bagillion other VB programmers probably wouldn't either. He basically said that MS knew they had threw the VB coder base under the bus but didn't care much either way.
:-)
I did a large application long ago starting with VB 2.0 thru VB 6. That was an "interesting" progression with each version. As some have pointed out MS threw in some crazy changes along the way, but for the most part each version built on the previous version. The notable exception being the data libraries... DAO, RDO, ADO, etc... Each time re-inventing the wheel, but by version 6 with ADO it seemed like MS had hit upon a good compromise of power and accessibility.
Than came
I remember being on the phone with a buddy from MS, after trying the
So I stayed away. I don't write a lot of code anymore and in the intervening period I've used a smidge of C, a bit of python (which I like a lot), a little Perl, and a decent amount of PHP.
Then came Visual Studio 2005 in the MSDN pack... I figured, what the heck. I had a little app that I had an itch to write and surmised that a clean start would be a good thing.
I loved it! The IDE is beautiful, it really is very nice to use. The controls provide a huge selection, the syntax is familiar enough to be comforting, and it just seemed to work. I was pleasantly suprised.
I then I tried to access some data. Not your run of the mill CRUD but some slightly advanced scenarios. I tried to fight my way through the new "datasource" wizard thingy and all the funky objects it creates.
I couldn't do it. It reminded me of Access in the ways that it makes incredibly simple things seem incredibly difficult. So I fought it for a few days trying to understand a sane approach to accessing data that would provide the sugary goodness of data bound controls with the clean simplicity of controlling the behind-the-scenes data access plumbing with code.
I failed miserably. On about the 4th day, I did something evil that Visual Studio didn't like. All of the sudden, my controls were gone from my main form. They had just disappeared. I still don't understand exactly what I did, but something made the IDE yak... No error messages, no warnings, just gone. I immediately deleted all my project files, including the svn archived versions that I could have went back to.
VB 6 gives me everything I need to build my little app, which is what I use VB for now anyway. For anything consequential we will continue to use LAMP, Java, or C++.
In the long run MS did me a favor by bitch slapping me away from their development tools and hence windows systems in general. I wonder how much that has to do with the fact that we run 80% linux boxes...
Hopefully a lot!
I searched Monster.Com for all jobs, I didn't limited to geographic scope because there are hot spots for both languages. My home town for example, the UW Madison CS degree focuses heavily on Java, so we have an absurdly large number of skilled Java developers in the area, which in turn leads to a lot of Java based work. But the head hunters I've been talking to recently say that the Java market is much tighter in Chicago while .Net is on fire.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
If you use Visual Basic, this book is definitely not the help you need.
Build a tool even an idiot can use and only an idiot will want to use it. -S.O.B.
I work for a company whose main product is a VB6 app that has had hundreds of thousands of pounds invested in it over many years. When .Net came out we quickly realised there was no way to simply convert the code to VB.NET. The upgrade wizard is a joke. The only way to move to .NET is to do a rewrite, but we don't have the time or money to do that. I suspect many companies are in this position, but they don't want to make to much of a fuss as they do not want their customers to know about the problem.
Even if we had £400,000 to invest in a rewrite, would it make sense to do in in C# or VB.NET? After all, what is to stop Microsoft from screwing us again? I find myself wishing we had written it in Java from the beginning. It would have been cross-platform and would not now require a re-write.
Has anyone else out their been screwed in this way too?
P.S. You can forget Mono, that will never be able to keep up with Microsoft's gargantuan changes, so that's not really a migration option if Microsoft decides to ever dump .NET.
The product I'm working on for my job is a rather complex, real-time, client-server application written in VB for the most part. It has evolved for about 12 years and includes today about 3 million lines of code. Works great. Performance is unbelievable (positively) for a VB6 app.
.NET successor and falling back to COM interop as soon as possible.
/.). Given this, and no matter how superior the .NET platform was, I still find it really incredible that MS did not provide any decent solution for migrating the huge VB6 code base to the new technology.
.NET appeared? No corrective or security updates any more. No such thing as a phasing out period.
While the transitions from VB4 to VB5 and later to VB6 had been relatively easy (upgrade GUI controls, recompile), migrating to VB.NET quickly proved to involve a great risk for an incredibly high cost. The migration wizard provided by MS was something to laugh - or cry - at, for example failing to upgrade most controls & components to their
We have abandoned the migration option in favor of a progressive rewrite (in C#). There is no other viable option, from an economic point of view: our customers don't care at all about the technology on which the system is based, but they do care about new useful features being added to the system at regular (reasonably short) intervals.
Not so long ago, VB had replaced Cobol as the world's most used programming language (with C, C++ or Java far behind - this had been covered on
Did I mention that VB6 became obsolete as soon as
Nowadays many people would say that it's the price of using a proprietary development environment (compiler) compared to an open source one. However probably no one would have dared sustain such an opinion when the development of our product started 12 years ago...
Some time ago I read someone's proposing an open-source VB6 compiler as an interesting project: has anybody heard something about that?
VB6 was great for data entry apps that backed up to mssql or access. It was easy to write, debug, and get working in general. The whole pick the tool to solve the problem type of thing...
Built in things I have found so far:
- MD5 function - REALSQLDatabase... built in just like a set of functions. - sprites - cropping, scaling images (gif, jpg, bmp, more) - simple 3D - network communication in a few lines
In VB I was constantly using API functions to do advanced stuff. In RB things are included... no need to hack. Also, AFAICT, no need for a bunch of dlls in your system folder for it to work... just the executable.
How do you spell "whoa"
Until Visual Studio returns the ability to create a stand alone executable program there will always be a place for VB6. Microsoft could not have made their AntiSpyware without it!
"Can there be a Klein bottle that is an efficient and effective beer pitcher?"
Also, the damn thing's everywhere. Suppose you have some dullish office data handling task. The sort of thing your average white-collar drone will spend several days working on in Excel, click, copy, paste, add up, repeat...
You're smarter than that. You know that this kind of repetitive shite is best done by a computer. Very well... but you aren't in the IT department, you don't have admin rights to install anything, and God help you if you download and run anything not authorised and signed off on by the Proper Authorities after at least seventeen two-hour meetings about it.
And yet here is VBA. Hiding just under the surface of every one of these mundane office apps you use every day. OK... for a = 1 to lots, sht.Cells(a,1), adodb.recordset, this, that, the other, output to here... done!
If you're a geek in the wilderness, VBA's a godsend. Or perhaps a deal with Mephistopheles... either way, it gets results :-)
Real Daleks don't climb stairs - they level the building.
That could depend on what you want to do with it. The best idea I've come up with is writing a brainfuck chatbot, then porting it to C, to try and win the obfuscated c code competition. Besides, maybe Brainfuck is a good language, made by a bad programmer.
12 steps is too long. My ideal plan is: 1) Quit 2) Relapse 3) ??? 4) Profit!
I was a long-time VB developer. "Was" is the key word. I worked for a major MS partner, and started working with the pre-alpha releases of .Net. After a short while I decided that VB.Net was a complete joke, and decided to switch languages (I had originally been a C/C++ junkie, so no trouble there).
.Net class library, yielding code that is almost legible, if it weren't for the stupid constructs used to bolt VB onto it.
I've spent the last 5 years doing Java development, and was recently called in to overhaul a VB6/VB.Net application. I agreed to do it, since rosy memories left me thinking it would be better than it actually is.
Lo and behold, VB.Net is worse than I remember it. The last 5 years of Java development have spoiled me. I wouldn't mind doing C#, but the customer requires VB. Everything I told my previous customers about VB being dead was more prescient than I ever could have believed.
At this point, I can categorize VB programmers into 2 categories:
1) Holding onto VB for dear life, writing their same VB code around the obfuscated constructs forced upon them by VB.Net.
2) Holding onto VB for dear life, but trying to adopt the
On the other hand, MS has given VB programmers access to things they've always wished for. The problem is that the syntax is contrived and "bolted on." The downside is that the syntax is incredibly obtuse. "AddressOf"? I thought we weren't supposed to use that?! Now it's required?! (A collective response, as a C++ programmer I have no problem with function pointers.)
At this point I can say that I honestly feel that anyone holding on to VB.Net has a doomed career. If you can't make the switch to C# (add curly braces and semicolons, subtract the cruft), then you need to get out of this line of work immediately. And, better yet, switch to Java, which has a superior class library, more consistant syntax, and will run on any platform.
At this point I'm waiting for my VB.Net contract to end, and have already informed the companies I subcontract through that I will not take any more MS related contracts. On the mornings that I have to work in VB.Anything I wake up with a knot in my stomach dreading the hoops I'll have to jump through to get my job done.
Long live Java/Eclipse,
The Waxed Yak
I thought MS was migrating its customers to C# or J# ?
"Because vbscript works with excel, word, access - learning vb gets you to work with almost every microsoft product from asp server scripting to making vb6 windows applications to client side vbscript coding to office to scripting for other apps. "
But guess what--Javascript can do all those things as well. The whole idea of COM was that the calling convention is accessable to any language, unlike the insular world of Java. I have written lots of Windows Script Host scripts in Javascript and have done a whole ASP site in Javascript. It's especially nice because you use the same language on both the client and server side of a web app. And don't tell me you use VBScript for client scripting, at least don't say that out loud here on Slashdot.
The problem with C# (in my experience) is that it is very fussy (as compared to VB.NET or especially good olde VB6). For instance, I spend a lot of time in C# doing type conversions, which in VB6 were far more straightforward.
.NET has enough to worry about without having to deal with fiddly type conversions (System.Data.SqlClient, stand-up, you are a right royal PITA to work with in C#, as I keep having to worry about the differences between SqlInt16, SqlInt32 etc., when by rights I ought to be able to interface with SqlInt32 and not have it fall over if it encounters a sql tinyint).
.NET in general, but it is used by a wide variety of developer types and abilities, and so why make life harder for those for whom VB.NET is the natural choice?
If you're coming from a C++ background, C# is most definitely the way to go, but the leap from VB6 to C#.NET is quite a few rungs up the ladder in terms of the discipline that is needed. Another thing that infuriates me is the fact that it's case-sensitive - the number of times I forget this and end up wondering if I'm using the correct class library, because the popup doesn't appear, only to find I've not capitalised it.... grrrrrr!
Fact is, though I set out firmly wanting to side with the pro-C# folks, I am finding that life is simply more straightforward in VB.NET, and I would suggest that anyone moving from VB6 to
I do like
John
Visual Basic 6 > VB.Net enough said
vb6 - native code, fast code creation, easy to learn.
vb.net - non native code, bloated language, hard to learn.
The is no point to vb.net it can be converted directly to c#
You may as well use c# you will type less for a start!
The advangage and disadvantage of vb was its lack of OO.
OO isnt always a good thing - there is still a place for procedural programming.
Visual Basic 2005 Jumpship
Bitter and proud of it.
Who knows what his code is doing- the only time I've seen delays is with slow machines or sucky code.
Cogito Ergo Sum
"There are no crappy languages, but there are a lot of crappy programmers."
Really? What kind of languages do crappy programmer design?
If they cannot create crappy languages, then what happens when they come to design a language?
Do they smarten up just in time?
(Variation of a Dilbert rebuttal to the "there are no stupid questions" cliche).
${YEAR+1} is going to be the year of Linux on the desktop!
Can't believe there are still VB 6 programmers out there who haven't jumped on the .NET bandwagon, but if so, it's time to get on board. Either way, we definitely need better resources for Visual Studio 2005 and this is a welcome addition.
So then what exactly is the difference between coding in VBScript and Javascript?
They have access to the same set of objects. Javascript does not have any language features that VBScript does not have.
Javascript has curly braces and type sensitivity but for most part any Javascript code can be translated line by line to exactly the same VBScript code.
I have a nightmare. I have this idea that unless I can learn VB2005 I will not be much use as a programmer. I like VB6, I have written meaty apps in it, but I'm over 40, maybe over the hill, and I guess I have to really sit down and figure out whether or not to make the leap. Just a personal opinion.