"I coulda had class! I coulda been a contender!"
--Terry, in The Waterfront

My recent articles have leaned toward the overview side of the spectrum, being as they've been "first look" articles and coverage of topics from a managerial viewpoint. Not this one, dear reader. Despite the "Round 1" appellation, this article is going to quickly dive right into the nuts and bolts of developing code. If you're looking for a breezy overview, this is not going to be your cup of tea.

The topic should be clear: Microsoft Visual Studio vs. Eclipse as development tools. But by the very nature of the subject, I'm immediately going to be ensconced in the .NET vs. Java conflagration, and I hope to bring you information that is as unbiased as one person can be. The good news is that regular readers of my columns already know my biases: the iSeries, RPG, JSP Model II, and Java, in about that order. I'm also more anti-Microsoft than pro-Microsoft, but that's from a corporate standpoint, not necessarily because of the products. In fact, I'm on record as saying that many Microsoft desktop products are the best of breed (I am an ardent fan of Microsoft Publisher, for example).

Next, if you've done any comparisons of languages and tools, you're probably deathly tired of anything that even hints at "Hello World" simplicity. While it's great to cram something like that into a screen shot for a marketing brochure, it's not going to give you any sense of the real capabilities of the product.

Leveling the Playing Field

In order to get around these issues, I'm taking a slightly unusual tack.

First, I've picked a test program that is neither simple nor trivial. Obviously, I can't get too terribly sophisticated, but I decided to actually answer a real working problem. The problem is this: I have a VPN connection, and because of a combination of settings on the various appliances on the network, it tends to lose its mind if there is no traffic on the tunnel for more than about 15 seconds. An empirical test determined that if I could ping a computer on the other side of the tunnel every 10 seconds, the connection would stay intact. So my project is to build a simple program that will allow me to ping an address repeatedly. I need to be able to enter the address and the delay, and then stop or start the process with the click of a button. (Author's note: If you think you can help me handle this particular issue the right way, please contact me offline at the email address at the bottom of this page. That could in itself get into another column.)

Second, I'm far more versed in Eclipse than I am in Visual Studio, so Visual Studio is immediately handicapped. You can take that into account as you read this, but at the same time, I'm going to even the odds a little by using a feature of the Eclipse platform that I've heretofore ignored: the Rich Client Platform (RCP). RCP is a feature that allows you to create Eclipse-like applications (that is, applications with all the UI capabilities of Eclipse) as a standalone programs, not as plug-ins to Eclipse. So while it's perhaps not a completely level playing field, in both cases I'll be tackling not only the language and tool, but my own ignorance as well. It ought to be fun!

Hardware

I have an unusual setup in which my primary workstation is a full-blown Windows 2003 64-bit server with dual 3.2 GHz Xeons and 2 GB of RAM along with 15 KRPM SCSI drives. I don't have a lot of response-time issues. But for real-world testing, I have a 2.9 GHz Celeron with 768 MB running Windows XP Home. I also use the smaller machine for surfing and Office tasks such as writing this column.

Speaking of the column, I've got about 1000 words for each product, so obviously I won't get very in-depth. I hope to follow up in future columns. I also hope we'll get some interaction from people who do this every day to point out where I've strayed miserably so that you don't have to make the same stupid mistakes I'll undoubtedly make. But me, I'm going in without a net, so to speak.

Visual Studio

Wow. Quite an impressive little piece of software, this. In today's article, I'll take you through the paces of creating a project in VB and running it.

Figure 1: This is the Visual Studio workbench, displaying the impressive Start Page. (Click images to enlarge.)

The Start Page is quite nice. It offers not only semi-static data such as your recent projects and some Getting Started entry points, but also the MSDN Visual Studio "portal" I guess you'd call it, with lots of recent news. I'll avoid discussing how much of this is news and how much of it tiptoes the line between information and advertisement, but it does point out something that's pretty prevalent throughout the product: a tight integration with the Web. This is not news to anyone using newer Microsoft products. Nearly all Office 2003 components, for example, have fairly seamless Web access for things like help or templates. Web-readiness is essential; much of what I found myself doing while getting started with Visual Studio .NET was surfing the Web looking for examples.

Decisions

Among my first decisions was choice of language. I decided to go with Visual Basic (VB). In a previous life, I was relatively proficient in C and C++ so C# syntax wouldn't really be an issue, but in general I consider those to be system languages as opposed to an application language like VB. VB is better-suited to a more ad hoc style of development, and since I was just trying to get something working, I figured VB was the way to go. Once I decided that, it dawned on me that since I was using Visual Studio 2005, I had no choice but to create a VB.NET application; Visual Studio doesn't support old-fashioned VB6 code. So it turns out the language choice was pretty simple after all: VB.NET or nothing!

Then, the only issue was to figure out how to ping. I started out by creating a new project. You are presented with a dizzying array of options when you create a new project, but with a little intuition, I was able to winnow out the inappropriate options and settle on Windows Application, as shown in Figure 2.

Figure 2: This is the New Project wizard, ready to create a new Windows application.

I created my Ping project and started working. You might have noticed the P: drive letter in the Location field; P: is a shared network drive, although it is served from my development machine and so is just mapped using SUBST. It allows me to test locally and then distribute code to other machines without having to worry about changing drive letters. As long as everyone points to P:, we're in sync!

Designing the UI

One thing Microsoft has down to a science is the ability to build thick-client GUIs using a WYSIWYG editor, which you can see in Figure 3.


Figure 3: The UI editor in Visual Studio is superb.

To the left of my newly designed PING form are tabs, one of which is the Toolbox, which lets you select components to add to the screen. If anything, the UI for Visual Studio is a little too flexible (although this is more of a complaint about my own lack of knowledge than the tool itself). For example, in the default mode, when you bring the toolbox up by clicking on the tab, it covers the form you're working on (see Figure 4).


Figure 4. Here, the Toolbox comes up, obscuring the form I'm working on.

If you click on an option, the toolbar doesn't go away. If you click on the form, the toolbox view goes away, but the UI component is placed at the point you clicked it. As it turns out, there are multiple ways around this. If you click and drag the component to the form, the Toolbox will auto-hide. You can then continue to drag your component to the appropriate position. Or you can take off the auto-hide option and the toolbox becomes a persistent component of the desktop, taking up real estate but making it easier to drag and drop things onto the form. And if you're short on space, you can even narrow the Toolbox almost to nothing. None of these were particularly intuitive, but I'm just getting to know the interface; you might find it a little easier to use.

Adding Code to the Form

The Visual languages tend to be very event-driven, and the editor is perfect for that part of the coding. For example, I want to start pinging if I click on the PING button. Later, I'll use the same button to stop the pinging. So nearly everything revolves around that button, and Visual Studio makes it simple to get started: just double-click on the button.

Figure 5: Edit the VB.NET code.

Note that the editor automatically creates the class for the form (Form1) as well as the subroutine for the button (which I called bPing when I added it). Luckily, I was planning on using the default action (clicking the button), since I'm not sure how to add event handlers for other actions. Certainly, it's not much of an issue for a button, but for example, I don't know how to handle exiting a field (for editing purposes). My guess is that it would be something like tIPFrom_Onblur, where tIPFrom is the name of the field, but there's really nothing that shows me how to do that.

Pinging!

And now on to the crux of the biscuit, coding the ping routine. As it turns out, pinging is quite easy in .NET 2.0. There is a Ping class, although you wouldn't know it from the examples on the Web. And that's where I have a real issue with Microsoft's handling of VB6 and VB.NET.

The current wisdom is that one of the great advantages of developing using Microsoft languages is how much code is available on the Web. One problem with this statement is that it holds true only for older tools. For example, I can find numerous examples of pinging with VB6. Which leads me to the second problem: There are too many examples, and many of them are horrible. Just a quick Google of "ping visual basic" (no quotes) immediately brings two completely different techniques to the fore. How does a beginner decide which to use?

That wouldn't be so bad if it weren't for the fact that nearly everything out there is for VB6. There is very little VB.NET example code available, and believe me, there are significant differences between the two. Not only that, but whenever you Google for techniques in .NET, you also tend to get a lot of C, C++, and C# clutter. That's the nature of the multi-language beast that is the .NET framework.

To make a long story short, the only examples I could find for the new Ping class are in C#, Microsoft's language of choice. I had to then translate the C# to VB, which requires something more than casual acquaintance with the languages but is still not terribly difficult. A little review of the documentation at the Microsoft Developer's Network site (specifically, the Ping class documentation) made it easier; the MSDN online information is still the best in the business.

After that, the actual ping operation required only a single line of code following four declarations:

The .NET Framework

As it turns out, however, it wasn't nearly so simple as that. Coding for the .NET framework is actually less than trivial. Two big things are delegation and exceptions. Exceptions should not be too difficult for most Java programmers; VB.NET has a standard try/catch syntax. .NET tends to nest exceptions a lot, so you may have to walk down the exception chain to get to one that actually indicates the real error, but it's not too bad once you get the hang of it. The "Not ... is Nothing" syntax is a little weird, but you get used to it.

Delegation, on the other hand, is a very weird concept. Once I understood it, it made sense, and as it turns out the VB.NET implementation is both simple and elegant, although very alien to a typical BASIC programmer (or an RPG programmer, or in fact just about any procedural programmer). The only way I got it was by hearkening all the way back to my assembly language days, where we had to lock sections of code during interrupts.

As far as I can figure, the idea is that .NET code will never allow multiple threads to access the user interface. That is, a form and its components belong to a single thread, which is the UI thread, and only the UI thread can touch the components. Anybody else tries, and the program bombs. Most of the time this isn't an issue, but in event-driven programming, the idea is that you have asynchronous events triggering actions.

In this particular application, I want to perform a ping every n seconds. In order to do that, I need to have a timer thread that regularly fires an event. Creating the timer thread was easy. I just created a new Timer object and attached a handler routine using the AddHandler opcode. However, the timer thread can't directly update the UI components, so it needs to use a delegate.

Creating a delegate was relatively easy. I wrote a routine that updates the controls I need updated, and then I created a delegate to that routine:

It's not entirely clear in this listing that there are two distinct pieces. The first piece is the Private Delegate Sub UpdateDel(), which defines a type called UpdateDel. I made this as simple as possible. First, this is a delegate to a subroutine, which means it has no return value. Second, the subroutine has no parameters. Passing arguments to a delegate is a somewhat complicated and is a topic for another day; I get around that by letting the delegated routine use a member (strStatus) that is available to all the functions in the class.

The second piece creates a variable of type UpdateDel, sets that variable to the address of the routine UpdateStatus, sets the strStatus variable (which is used by UpdateStatus), and then invokes the routine. lStatus is the UI component being updated; using its Invoke function is what puts the update on the UI thread.

Pretty cool, eh?

Round 1 Done; Look for Round 2

OK, that's round one. I've walked you through the basics (no pun intended) of using VB.NET for a non-trivial piece of code. I haven't touched the issues of executing, debugging, or deploying the code; instead, I've addressed a couple of basic .NET architecture issues. In round two, I'll address those issues and hopefully have enough room to start in on the Eclipse side of things.

And for those of you who wish to have a good laugh at my expense, feel free to peruse my code. I'm including both the VB code and the Forms designer code. That's primarily because I'm not quite sure how to export the whole project (it might be as simple as zipping up the project folder, but I'm not certain).

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..