The next thing to do is allow the user, in this case, me, to add, edit or delete contacts. Deleting is a subject which will need further investigation, but at this stage we will just allow simple deletes.

First we need a form. So we will create a new inherited form called ContactEditForm, and inherit from our BaseForm. On this form we will place some Labels, Text Boxes and Buttons, so that it looks like the diagram below.

There are a couple of things to do, all of them fairly straightforward.

First, we have to be able to get to the form, and this is done from the Contact Form, using the New and Edit buttons on that form. We will create a new Contact object in the ContactEdit form by declaring a new private instance of the Contact class, and make it accessible by creating a public property, called Contact. All very standard. The code looks like this:

   Private m_Contact as new ContactEntity

   Public Property Contact() as ContactEntity
      Get
          Return m_Contact
      End Get
      Set(ByVal Value as ContactEntity)
          m_Contact = Value
      End Set
   End Property

Visual Basic is very verbose, and in C# the code to do the same thing is much more concise. The good thing is that the IDE does most of the work for you.

To edit a contact the user needs to select a contact from the Listview control. Selecting the contact creates a new ContactEntity object and this object is passed to the ContactEdit form in the Set part of the property. So m_Contact, in the ContactEdit form is the same object as the Contact selected in the Contact form. The code to open the ContactEdit form also contains a command to set the Text of the ContactEdit form to Edit Contact

If the New button is pressed then the ContactEdit form is created but the Text is set to New Contact

and the IsNew property of the ContactEntity is set to true.

In either case the form is then opened with the Show method.

Next we need to set up databinding. In previous versions of VB databinding was a sad joke, but it is much improved in VB.NET. There are a couple of ways to set up databinding. I usually do it in code like this.

txtSurname.Databindings.Add("Text",m_Contact,"Surname")

And so on for each of the text boxes. Then it is merely a matter of attaching a Save method to the Save button, and a Delete method to the Delete button. We will revisit Delete at a later date when we consider validation.

The Close button has a form.close method attached and we are almost done.

There are two final things to do. The first is to set the Tab order which is done in the designer from the View menu. You merely select Tab Order from the menu and click each control in the order you wish to tab through them.

Lastly, we set the AcceptButton of the form to Save and the CancelButton to Close, and we are done.

The reason I call this a sub-system is that it really stands on its own. All it does is list all the contacts I have and allow me to add new contacts, edit the details of existing contacts and delete contacts. It will interact with the other sub-systems, but it stands on its own.

If I was building this for a client I could deliver this subsystem prior to building anything else. And if the client decided that they didn’t want the rest of the application then all it would mean is some quick changes to the Main Form and they would have a complete system.

Most of the procedures I use here will be followed in subsequent sub-systems and forms, so I will go into detail for this section, but later on we will move much more quickly.

First thing to do is create a new inherited form called ContactsForm. It is inherited from the BaseForm, as most, if not all, our forms will be. We then hook it up to the menu item on the Main Form called mnuContactDetails. The code looks like this:

Private Sub mnuContactDetails_Click(ByVal sender As System.Object, _
   ByVal e As System.EventArgs) Handles mnuContactDetails.Click
        Dim frm As New ContactForm
        frm.ShowDialog(Me)
End Sub

Notice that, because every form is created from the form class it must be instantiated before it can be used, just like any other object. This is quite different from previous versions of Visual Basic.

Back to our Contact Form, and we will put some controls on it. I want to show a listview which will list all the contacts together with phone number. I will also show all the other details for the contact in text boxes to the right of the listview. There is some disagreement between developers as to whether we should use text boxes or labels for read-only information. In reality, it doesn’t really matter. I use text boxes for information that is coming from the database, and use labels to label things, like other controls. If you are goint to use a text box, as I do, then you need to set the Read-only property to True, otherwise the user will think that they can change the values. I also set the TabStop property to false and the BorderStyle to None. If, as I do, you have used a different background colour for the form than the default control colour, then you also need to set the background colour of the text boxes to the same colour. These properties can all be set at once in a matter of seconds, or you could, if you wished, sub-class the text-box to look just like you want and use the new inherited control. This is probably a more object oriented way of doing it.

Now for a bit on the code. Whenever I fill a list type control, such as a Listview or Treeview, or even a list box or combo box, I always do a couple of things.

• Set the cursor to wait, that is it will show an hourglass, or whatever equivalent cursor the user has set up as their wait cursor.
• Prevent the control from updating itself until all the items have been placed into the control. This speeds up the filling of the control.
• Clear the control
• Populate the control.
• Update the control
• Reset the cursor.

So the code looks like this. My Listview control is named lvContact.

   Cursor.current = Cursors.WaitCursor
   lvContact.BeginUpdate()
   lvContact.Items.Clear()
   '////////////////////////////////////////////////////////////
   'Code for populating the listview goes here
   '///////////////////////////////////////////////////////////
   lvContact.EndUpdate()
   Cursor.Current = Cursors.Default

Populating the listview can be done in a number of ways. First we need to remember that the Listview control is not data aware, so it cannot be databound. You can create a User Control that is data aware, but it is not really necessary. I use an Object-Relational mapper called LLBLGen to create my data layer. There are other O/R mappers around, or you can do it another way. I wouldn’t recommend using datasets, a lot of overhead for no advantage. LLBLGen allows me to create read-only lists which can be sorted, and are returned as data rows. So I add a sort expression and create the list.

So my code for populating the list view is the following:

   Dim myrow as Datarow
   Dim LVI as ListViewItem
   For Each myrow in Contacts 'Contacts is the name of my list
      LVI = lvContact.Items.Add(Cint(myrow(0)))
      LVI.SubItems.Add(Cstr(myrow(1)))
      LVI.SubItems.Add(Cstr(myrow(2)))
   Next

The Contacts List, which I created in LLBLGen, has three fields, ContactID, Name and Phone, and I created them in that order, so they are the fields returned by the datarow. I could have used name fields, rather than refer to them by their index, but this way provides a littel better performance.

There are just couple of things left to do. First, when a contact is selected in the ListView we want to show their details in the Read-only text boxes on the right of the form. So I have declared a Private variable m_contact as a ContactEntity. That is the name which LLBLGen has given to Entity created from my Contact table in the database. When I select a contact I create a new ContactEntity object

m_Contact = New ContactEntity(Cint(lvContact.SelectedItems(0).Text))

I then use the properties of the m_Contact object to populate the text boxes.

Finally, I need to hook up the buttons. The Close button is easy, I just close the form with a Me.Close() method. The other two buttons required the creation of a new form, which is the subject of the next episode.

This has been a long article. We won’t go into as much detail with most of the other forms.

But there is a problem. I use LLBLGen, an Object Relational Mapper, which maps my database tables to classes. It creates a number of classes:

• Entity classes – the classes which map to the tables
• Collection classes – collections of entities
• Typed List classes – read only lists which include the specific fields from tables or relations that I might want to use, for example in list boxes
• Classes formed from relationships that I establish
• Various factory and helper classes for sorting, filtering and other assorted functions.

While there is no problem with the Contact entity, or table, that I will create, It is worthwhile mentioning here the procedure that I follow.

Data is held in a relational database, which follows fairly strict rules. Relational databases can be described in purely mathematical terms, and there is a well-deveoped relational theory to support them.

But the object which I use to populate the controls on the forms, such as text boxes, list boxes, etc, do not necessarily relate 1 to 1 with the tables. So my thinking is in terms of the objects and classes, but my O/R mapper does not translate classes into data tables, rather it maps data tables onto classes.

So I need to consider, first what objects I want to show, and from those determine the data that is needed to create these objects. Once that is done I can then apply relational theory to create the database tables. The O/R mapper then generates my classes which I use to create the objects.

As I said earlier, it is not a problem with the Contacts table or classes. I will create a table for Contacts and map it directly to a Contacts entity.

The Contacts table will consist of the following fields, or attributes, or columns, depending upon your prefered nomenclature – isn’t that a great word!

• ContactID, the primary key and we will make it autoincrement
• CompanyName
• Surname – the surname of the contact person within the company
• FirstName
• Add1 – the street number and name, or post office box
• Add2 – the town or suburb
• Postcode
• State – that is geographical state, like NSW, VIC etc
• Phone
• Mobile
• Email

I have realised that I left fax out of this. I have already built the form, but I have made a note to amend it, at some stage soon.

The next thing to do is to create the form, the subject of the next article.

I will go through this in detail because it is the same procedure that I will adopt for all my forms, with a few exceptions.

In Solution Explorer I right clicked on the name of my project, which in this case is HourWin, and in the pop-up menu selected Add inherited form. In the Add New Item dialog box I gave the form the name MainForm and clicked OK. A new dialog appeared asking me which form I wanted to inherit from. I clicked BaseForm and OK. A new form was created.

I could have merely added a new form, and in the code changed the inherits to BaseForm.

For this time only, I have to change the Project Properties so that the new MainForm is the start up form.

I now have a form which shows me two red lines running down each side of the form, and 25 pixels from the border. I will use these as guides to place my controls. The code entered into the paint method in the BaseForm ensures that these only appear if the form is in Design mode.

So now I need some menu items. I will follow the normal Windows standard and have the first menu item File, and under that I will place Exit. I also know that the first Form I am going to build is for my Contact subsystem, so I may as well create a menu item to access that form.

I build these menu items using the menu control from the toolbox. The File menu item will not have any code attached so I will leave it with its default name. The Exit item will have code so I will change its name to mnuExit, and in the code view simply tell it to end. At some stage I might want to add other code to perform clean up operations, but I am not sure yet. At this stage all this window does is provide me with an entry point to the application sub-systems.

I haven’t worked out the design of this form yet, so to get to the Contacts section I will add another main menu item, Contacts, and under that an item Details with the name mnuContactDetails. This gives me the option of adding more windows which relate to Contacts at a later stage, if I want them.

The final thing to do is show the name of the application in the Main Form. In the code after InitializeComponent I added Me.Text = MyName. MyName can be set in one of two places. In an application configuration file or in a module. It doesn’t really matter which. The point is that it only has to be set once. I set it to Midnight Hour 1.0, and now we are done. We have a form that does nothing except exit the application.

The application will be written in VB.NET. So the first thing is to create the folders where the work will be done. To do this I opened up Visual Studio and created a blank solution called MidnightHour. That’s what I will call my new masterpiece.

I had decided that I will use, at least at this stage, an Access database, so I may as well create it now. In the MidnightHour folder that was created by Visual Studio I created a database and called it Hour.mdb. I am not doing anything with it yet, so I won’t add any tables at this stage.

There are a number of subsystems within the application but I am still going to need a Windows form to serve as an entry point to the application. At this stage I haven’t designed that yet, so I will just create a main form with a menu that does nothing more than exit the application. When I create each of the subsystems I will add a menu item which I can use to access each system. It might make sense to design this now but I would rather do some coding than graphic designing, so I will do it later.

What I will have to do, though, is create a template form from which I will inherit all my other forms. There are a few reasons for this. First, because this is going to be used on my computer I can set the colours to whatever I want. I don’t like the Windows control background colour much, so I set the background colour to white. But there are more important reasons.

First, I want to have a standard look to my windows forms. Same colour, same font, same icon, and, most importantly, a standard border, or padding between the window border and the window controls.

To accomplish the first tasks I set the background color of my template form, called BaseForm, in this case to white, attach an icon, and change the font to Tahoma – I think it looks much better than the default Microsoft sans-serif.

Then change to View Code and select BaseForm events in the Class drop-down list. In the Methods drop-down list I select Paint. This will fire whenever the form is painted. I added the following code:

If Me.DesignMode = True Then
          Dim myPen As Pen = New Pen(Color.Red)
          e.Graphics.DrawLine(myPen, 25, 0, 25, Me.Height)
          e.Graphics.DrawLine(myPen, Me.Width - 25, 0, Me.Width - 25, Me.Height)
End If

The last thing I want to do with the Visual Studio designer is to ensure that controls get a Windows XP look. Controls such as the Button can have a number of Styles which are set with the FlatStyle property. If you set this style to System you can have apply XP themes to these controls. But in order for these themes to apply you need a file called applicationname.exe.manifest. This is an XML file and it contains the following code:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0"></assembly>
< description>Windows Forms Common Control manifest</description>
  <dependency>
    <dependentassembly>
      <assemblyidentity type="win32"
      name="Microsoft.Windows.Common-Controls"
      version="6.0.0.0"
      processorArchitecture="X86"
      publicKeyToken="6595b64144ccf1df" language="*" />
    </dependentassembly>
  </dependency>
</assembly>

The last thing to do prior to any coding is to set up LLBLgen, my O/R mapper of choice. I won’t go into the details of doing that here because all O/R mappers are set up differently. But because I don’t have anything in the database it doesn’t do much yet. All I have done is create the folders and set the preferences.

I told LLBLGen to create a data access layer, and called it DAL. It creates a number of folders for me and created a new VB.NET project called DAL. I now have to add it to the solution and set some references to it.

And that is the end of setting up.

First off, UML purists may not like my diagrams, but I know what they mean, and I use them to assist me. But this one is pretty obvious.

There are a few things to notice. I have separated each of the subsystems and I will build these separately. This makes it easier to build, because, while there will be a lot of interaction between each of the subsystems, they are each, more or less, complete systems in themselves.

I think this approach also makes for better encapsulation. I need to look after the interfaces between each subsystem, but hopefully I can keep the implementation in each system fairly well hidden.

The database will be built incrementally, and that means that the database mapper will need to be updated whenever there is a database change, but that is no big deal, it takes less than a minute to do. And by only changing the database and the mapper to what I need at the time I avoid building stuff I don’t want – the YAGNI (You ain’t gunna need it!) principle.

I have put the printing as a subsystem, but at this stage I am not sure about that. Certainly I will add some printing classes that will service each subsystem. These are standard printing routines that I use in many projects. But whether I need some printing stuff in each of the other main subsystems or not, I’m not sure yet. I think I might, but that is something to look at down the track.

The final decision I had to make at this stage relates to the Contacts subsystem. Should I have a Clients system, for existing clients, and a separate Contacts system? Or should I do some sub-classing – a client is a contact with the additional property of having work done, and some extra methods? At this stage I am thinking that there is no difference between a client and a contact. When I have finished some work for a client they are just a contact – I still have to get more work from them for them to be termed a current client. Or so my thinking is at this stage. But I will see when I analyse the contacts system more fully.