Exploring VB .Net from a VFP Perspective (Part III) (by John Koziol)

Sometimes I feel like I'm repeating what others have already written about .Net from the VFP perspective. To those authors who have written extensively on the subject, notably Kevin McNeish, Cathi Gero, and Les Pinter, I apologize for any overlap. Hint to readers:  While I can't endorse third-party products, do an author search on any of the above in Amazon for recommended further reading.

Onward!

A core difference between .Net and VFP is that it's possible to hide the code implementation of some objects in metadata, for example, when you create a form in the Form Designer. In fact, it's pretty easy to put together a complete application without ever writing a single DEFINE CLASS or CREATEOBJECT("Form"). This is because VFP can interpret the metadata (.SCX/.SCT for Forms) directly. 

Not the case with .Net.  First off, there are two types of forms in .Net - WinForms and WebForms. Were not going to address WebForms at this time; WinForms are pretty much the same as VFP Forms.  And WinForms are constructed purely by code which is intepreted into a visual representation in the IDE.

Go into .Net and start a New Project. Choose Visual Basic projects from the dialog, and choose Windows Application from Templates. Don't worry for now what the name and solution location are for now. Click OK.

You'll be looking at a WinForm. In the upper right, click on the Toolbox button (usually on the upper right), which uses the same icon as the Designer Toolbox in VFP. The list of stuff you can add to the form should appear on the left, by default.  Choose "Button" and drop a Button on the center-bottom of the Form.

Pretty similar to the VFP experience, eh? 

On the upper right should be the Solution Explorer; if not, you can choose Solution Explorer from the View menu. The Solution is probably named WindowsApplication1.  Note that the Solution is kind of a placeholder for what the final output will be:  an EXE or DLL or whatever. Beneath that will be the Project, also named WindowsApplication1 which is almost exactly analogous to a VFP Project. 

Beneath that will be a folder-looking icon with the title References.

References refer to DLLs needed by this solution.  Since this is a Windows application, .Net already includes critical components of the .Net framework pertaining to UI and system stuff.  A rough analogy to the functionality provided by References is akin to VFP class libraries, although, VFP does not require class libraries for basic functionality.  Recognition of basic classes, such as Forms and CommandButtons, is built into the VFP runtimes. Not so with .Net. Each DLL listed establishes a namespace, that is, a collection of classes and other stuff.

Next in the Solution Explorer comes  AssemblyInfo.vb. In it's simplest form, this is where you can set version information, copyright, et al.  Very similar to the options available from the Version button in the VFP Build dialog.

And then, of course, Form1.vb.  This is the designer you first saw when you created the new solution. As I mentioned before, unlike VFP which stores Forms and Classes created in the Designers as metadata, .Net interprets code to present the visual representation.  So where is that code?

Right-click on the form and choose View Code from the shortcut menu. The screen changes to a code editor with two Comboboxes.  These show the object and methods, respectively.  By default, these will be set to Form1, and (Declarations).  The code will appear to be pretty simple:

Public

Class Form1
  Inherits System.Windows.Forms.Form

+[Windows Form Designer Inherited Code]

End Class

Essentially, you're not seeing much of anything here because we haven't added any code to the Form beyond that added automatically by the Designer, which compacts that code into a region. I'm not going to reproduce it here (at least not now) as it's way, way long but within the Inherited Code region is all the code to create the form, add the button to it, and define some inherited behavior.

If you return to the rightmost combobox above the code window, you can choose other areas of the Form1 code to look at such as New or InitializeComponent.  If you choose one of these, the designer code will be expanded as the Windows Form Designer Inherited Code contains that code.  Like VFP, if a method has code in it, it will be bolded like New and InitializeComponent. 

Notice that Finalize isn't bolded?  If you choose that method, the beginning code for that method is added to the code window automatically, as in:

Protected Overrides Sub Finalize()
   MyBase.Finalize()
End Sub

So that's the basic IDE and components lesson for today, folks.  I know I've probably created more questions than answers but in my next post we'll examine the code the designer created and what some of those weird keywords are ('Friend' ... what the hell is 'Friend'?).