Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×

Visual Basic 2005 Jumpstart 169

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
This discussion has been archived. No new comments can be posted.

Visual Basic 2005 Jumpstart

Comments Filter:
  • by Orrin Bloquy ( 898571 ) on Monday March 06, 2006 @02:06PM (#14859639) Journal
    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.
  • How about "why"? (Score:3, Interesting)

    by DogDude ( 805747 ) on Monday March 06, 2006 @02:06PM (#14859646)
    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.
  • by Anonymous Coward on Monday March 06, 2006 @02:27PM (#14859842)
    I disagree. With VB.Net, there's _zero_ reason to switch to C# - since thanks to the CLR the languages are just as powerful; with VB having a slightly more agile syntax. For the grandparent's opinion about becoming familiar with C/C++ -- learn C or C++ to augment your VB.

    Personally, I think C# and Java (which I've invested almost a decade learning/using) are pretty much never the best solution anymore. Anything I can do in Java I can do better with a mix of Python (or Ruby) and C. Java (and C#) are mediocre compromises of languages that aren't as well suited for high-level programming as Python; not as good at OO as Ruby/Lisp; and not as good for low-level tasks as C. IMHO the only reason they're used is when a middle-manager wants to force a single-language-for-everything because Sun or Microsoft took him to lunch.

    Use the right tool for the job.

    In the windows world, I'd recommend VB + C++.
    In the *nix world, I'd recommend Python + C.

  • by RingDev ( 879105 ) on Monday March 06, 2006 @02:33PM (#14859898) Homepage Journal
    I disagree. VB.Net is symanticly very similar to VB6. Almost identical. Vb.Net is Object Oriented, and it's design considerations are vastly different from VB6. The problem most VB6 developers run into is that they know the syntax and they expect it to work a specific way. What I tell most people who talk about learning VB.Net is to take a Java or C# class, becuase they are both OO languages that will remove the expectations you have from knowing the syntax. Once you can wrap your head around OO design, jump back to VB.Net and things will make much more sence.

    -Rick
  • VB to Python (Score:5, Interesting)

    by scorp1us ( 235526 ) on Monday March 06, 2006 @02:41PM (#14859979) Journal
    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.
  • by Unnngh! ( 731758 ) on Monday March 06, 2006 @03:25PM (#14860456)
    I think the main reason that vb.net is so popular is due to the hordes of vb6 programmers who are moving to .NET. There is a technet article (can't find the url now) about how MS documentation is moving more towards vb.net-only code examples. The company found that a) there are way more vb.net programmers than c# programmers and b) c# programmers are more likely to be willing to look at and understand vb.net code than the other way around.

    I cannot see that vb syntax, for someone coming in with no prior experience, would be better than c# syntax. VB.NET has more than twice the number of reserved words than C#, with no added functionality that I have been able to tell. The "Basic" in Visual Basic has long since been obliterated.

  • Re:How about "why"? (Score:3, Interesting)

    by RobinH ( 124750 ) on Monday March 06, 2006 @03:47PM (#14860728) Homepage
    We use VB6 for some specialized tasks... basically a nice colorful user interface where we need the use of a PC to store some data. The actual mission critical stuff is usually performed by some underlying real time control system. In that respect, what vb6 gives us is a rapid GUI development that can do all the things that LabView and Citect can do but has a lot more user support on the internet, and can integrate better with everything else. It's a good fit.

    Then we tried moving to VB .NET. I didn't have much problem with it since I have a hardware/software background, but most of the engineers around here are more focused on hardware and even though they "get" object oriented programming, see no need for it when all they want is a few pretty buttons on a screen for the user to start and stop some process.

    The nice thing about VB6 was anything I wrote could be debugged by someone with a basic level of programming knowledge. The stuff we wrote in VB .NET was more cryptic, and took longer to write. Even the concept of references confuses some people. We've had a very hard time switching over.

    Now if we only wrote desktop applications or shrinkwrapped software, I never would have suggested using VB6 in the first place, but for what we do, VB6 is a perfect fit, and VB .NET completely fails to fill that niche that we've been using it for (rapid GUI development). We've gone back to VB6 now, and we're keeping our eyes open for alternatives. ...and honestly, if we had to go to .NET, I'd rather switch to C#. I see no reason to have both VB .NET and C# .NET as separate languages - they're almost identical!
  • Re:How about "why"? (Score:2, Interesting)

    by RetroGeek ( 206522 ) on Monday March 06, 2006 @04:12PM (#14861009) Homepage
    What this means is that when you start your (my) 32k compiled app, it takes about 15-20 seconds for the libs to load up.

    Which is the main complaint about Java. That it takes too long for the JVM to start up.

    And from a post below:

    all the .NET apps I have run so far start up in 1-4 seconds.

    Which is my experience with Java.
  • Re:VB to Python (Score:2, Interesting)

    by RonMcMahon ( 544607 ) on Monday March 06, 2006 @05:21PM (#14861758) Homepage
    Your comment; "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." is very odd. It has me questioning if you are being entirely honest.

    As a VB developer since 1993 (and a commercial software developer since 1983), I can say that the language (pre .NET) hasn't changed in the way you present that it has. The only significant variant in the VB 'Family' was VB for DOS (yes, I'm one of a select few who actually built apps with this before it was killed off by Microsoft), but even then the product was vastly superior to any other DOS-based language editor that I'd ever encountered. In general I can take an application that I coded in VB 2 and open it with VB 6 and it will run without complaint. This is an accomplishment that your comments ignore - if you really are a programmer who builds 90% of your product in VB (pre .NET I assume), I'd think that you'd have to admit that the language did remain remarkably backward compatible. .NET isn't VB and therefore it really isn't fair to try to measure language evolution when the species tree is jumped rather than extended.

    As someone who continues to make a living in the VB 6 / VBA world, I'm very interested in learning about VB 2005 because I can see that the life of VB6, while still currently healthy, is beginning to wind down. My corporate clients won't be going to Python or Ruby or any other OSS-based platform anytime soon. These multinational businesses don't worry about the peanut costs of an OS, nor do they worry about the hegemony of Microsoft. If anything, the dominance of Microsoft is a comfort, as it helps to give them assurance that the company will be around for the foreseeable future, therefore betting on Microsoft technology will likely result in a win. Betting on marginal (from a business perspective) language like Ruby or Python et. al. is a sure-fire way to be fired as a technology manager. I'm not saying that this is how I like it, but more that this is the reality that I see around me in the Oil and Natural Gas sector in Canada.

    The source of innovation and transference to a new computing platform will not begin with large corporations, but will only (through financial necessity) begin within smaller cost aware businesses. Perhaps once all of the mice are on OSS will the fat cats begin to notice?

  • VB.Fred? (Score:1, Interesting)

    by The Waxed Yak ( 548771 ) on Monday March 06, 2006 @09:13PM (#14863341)
    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).

    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 .Net class library, yielding code that is almost legible, if it weren't for the stupid constructs used to bolt VB onto it.


    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 have hardly ever known a mathematician who was capable of reasoning. -- Plato

Working...