Building Windows Applications

Introduction

This is a sample chapter from Microsoft Visual Basic .NET 2003 Kick Start.

The Way Things Were

For most of Visual Basic's history, you did not need to specify you were building a rich-client application—all the applications you built were rich-client apps. Web development has never been the purpose of Visual Basic. This focus on developing stand-alone or client/server applications with a Windows user interface created a very tight bond between the VB language and the forms engine within it. There was no need to distinguish between the language and the tools for building an interface in VB6, but there certainly is in .NET.

In Visual Basic .NET, the technologies that enable you to create "standard" windows applications are part of the .NET Framework, available to any .NET language. This is a huge change from the way things were. In each of the following sections, before going into detail on how the new Forms technology works in Visual Basic .NET, I briefly describe some of the relevant details about Visual Basic 6.0 forms.

The Windows Forms Model

Forms in Visual Basic 6.0 were distinct files from other types of code (such as modules and classes) stored in two parts—a .FRM file that contained the code and the layout of the form and a .FRX file, which was a special kind of resource file that held any embedded resources needed by the form. When you designed a form using the visual tools, controls were added to forms and properties were set (such as the size and position of various controls) without any visible effect on your code. Changing the position of a button would change some hidden (not shown in the IDE at least) text (shown below for a simple one button "Hello World" application) that you could access and change using a text editor, but all of these properties were not part of your code. Setting a property in code was therefore very different than setting it through the visual interface.

Listing 3.1 The Code Behind a Visual Basic 6.0 Form

VERSION 5.00
Begin VB.Form Form1
  Caption    =  "Form1"
  ClientHeight  =  3090
  ClientLeft  =  60
  ClientTop    =  450
  ClientWidth  =  4680
  LinkTopic    =  "Form1"
  ScaleHeight  =  3090
  ScaleWidth  =  4680
  StartUpPosition =  3 'Windows Default
  Begin VB.CommandButton Command1
   Caption    =  "Hello World"
   Default    =  -1 'True
   Height    =  495
   Left      =  840
   TabIndex    =  0
   Top      =  480
   Width      =  1335
  End
End
Attribute VB_Name = "Form1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False

This special area of the form would also contain object references (in the form of GUIDs) for any ActiveX controls you used. Although editing the .FRM file directly was not encouraged, that was exactly what you had to do to fix a corrupt form.

Forms in .NET change everything just described. Forms are no longer "special" files; they are just code (.VB files in .NET), although they certainly can have associated resource files with them. Editing the properties of the form or of the controls on the form does not add hidden text to the form file; it generates real VB .NET code that sets the properties in the same way that you would in your own code. If you follow along with me and create a sample VB .NET form, you can explore the new forms designer and browse the code generated by your visual editing.

You might also like...

Comments

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.”