What Makes a Professional Application?
New Term
If you read one or more Visual Basic books or have worked with Visual Basic for any length of time, you've probably created many small programs, trying out Visual Basic's different features. After you do this for a while, you've probably asked yourself, "What do I do now?" By using all the tools, controls, and objects that you've learned, you can really impress your friends and family with the things you can get the computer to do. To do anything useful on your computer, however, you need to create larger and more complex programs, or groups of programs called applications. Whether the application you're creating is a small inventory program for the house, a personal phone book, or possibly a personnel tracking system for your office, many things go into creating it. If you take a close look at most popular pieces of software on the market, such as Microsoft Money, you can see that many different related routines create the single application.
Whether you're a seasoned programmer or a newcomer to the industry, everyone dreams of creating an application they can sell. Next time you go into a computer store, look at the numerous software applications available; most of them started as one person's idea. If this is where you're heading, you need to know how to plan your application accordingly.
When developing an application, most programmers don't consider what happens when they're done creating the application. If you're working for a company, the finished application is handled differently than if you're planning to sell the application yourself. Putting everything together into one package takes patience, time, imagination, a little luck, and lots of planning. If all goes well, the finished product will look good and work well.
Application Types
You might not realize it, but you can create three distinct types of applications. If you're just starting out as a developer, this might seem a little strange. An application is an application, right? Wrong! Depending on where you work, the type of application you're creating, and the application's final audience, the package you create will be quite different.
You might create three types of applications:
A personal application is one that you create for yourself and no one else. You probably won't create any help files or a manual for your own application. Also, because it's running on your own PC, you won't create any distribution disks. As you can see, a personal application is like keeping a private journal; no one else will ever know about it unless you tell them.
When working for a company, most applications that you develop will probably be internal ones used by other employees of that company or by company clients (for example, home banking software). If the application is completely internal, you don't need to consider any issues that deal with marketing the application. However, you do need to create a help system and a manual because you aren't the only one that will be using the application. Users must have some type of documentation to refer to when using the application.
If the application is for company clients or for retail distribution, marketing and advertising must be included in the overall process.
In the current Web-focused environment, these types even extend out to the Internet. You can develop applications that run entirely on a Web browser (like many banking applications), or run locally on the PC from the Web without installing the application before using it. Of course, there is the old standard of installing the application directly on the PC.
Picking the Right Application
New Term
Before jumping in and creating an application, you need to decide what function the application will serve. This decision isn't as easy as it might sound. For every idea that you can think up, probably 10 other people have had the same idea. Depending on whether you're creating an application to learn more about programming, something that you want to use at home, or an application to sell, you need to do some market research about what the application will do. If you're selling, it's very important to understand the type of person who would use it and how many you might sell. This helps you decide whether it makes any sense to go any further with the idea.
Without doing market research, you might create a great product that nobody wants or a product with so many competitors that it gets lost in the crowd. If you find that too many other products of the same type are already on the market, you might decide to select a different type of application or to place the finished product into the realm of shareware (discussed later in this book). For instance, you don't want to spend the time creating a word processing product with products such as Word and WordPerfect already on the market.
In short, you need to select an idea that's new—or at least different—and run with it. You also have to compare the cost of creating and advertising the product versus your available cash and expected sales. After you decide on the application, however, jump in and start the process. You definitely want to get your product to the public as quickly as you can, with the best quality possible.
Project Life Cycle
New Term
When creating an application, you must take several steps to ensure that it's done correctly. These steps are generally grouped together and called the project life cycle. Although the number of steps in this cycle can vary depending on the project's complexity, every project must take several universal steps. These steps, or standard life cycle (see Figure 1.4), allow you to plan each section of work and set goals to help verify that you're ready to move on to the next step.
){kind=link}
Figure 1.4 The standard project life cycle used in the creation of most computer applications.
Many newer Windows programmers tend to sidestep this approach and prefer to start coding their application immediately. Doing so, however, usually causes problems later on. If you don't plan or blueprint your application, you could wind up forgetting something important, thus having to redo large portions of your work just when you thought you were finished.
Design
The most difficult part of creating any application is deciding what it will do. When that's accomplished, the rest becomes relatively easy. The time you spend designing an application is the most important portion of the project. As mentioned earlier, some programmers like to jump right in and start coding. For every hour that you spend designing your application, you could wind up saving as much as a day of debugging time. If you start with a good design, you'll have considered many more of the situations that might cause problems later and resolve them before they occur.
TIP
Fixing design problems on paper is always easier than after they're coded.
In reality, the design step in the life cycle is a cycle itself (see Figure 1.5). Designing an application consists of creating the application's design description, functional definitions, technical definitions, pseudocode, and finally form layouts. From all these steps your actual Visual Basic code will flow. You should expect the design phase of the life cycle to take the largest percentage of time.
){kind=link}
Figure 1.5 The design phase of the life cycle is a cycle of steps itself.
After you write down the functional definitions for your application, you start translating them into a technical definition. As you move from one step to the next, you'll probably find things that you missed the first time; back up, rewrite that definition, and then continue forward again. In this way, when you start coding, it will be almost a line-for-line translation from your pseudocode to Visual Basic code.
If you think of designing an application the way a house is designed, you will get a good feel for the step-by-step approach you should set up before actually building the application. For example, you wouldn't put the roof of the house up before the walls are put into place, and you wouldn't put the walls up before the foundation is poured. You also wouldn't take a pile of lumber and just start nailing the wood together without a plan. If you did this, your house wouldn't be habitable. It's the same with an application. The plan, or design, is the foundation of the application. If you start with a good foundation, your application will hold up, no matter how hard it's used.
To get a good design, you need to understand what the application will consist of. A house and an application must be built according to a carefully laid out series of steps. In a Visual Basic application, you don't want to create any code before you create the forms, or create the forms or their functions before you know what types of forms you need.
If you build the application in the wrong order or leave a part out, it will be that much harder to add the code when the rest of the application is finished. It could take longer to finish, or never work at all. To design an application correctly, you must first understand what you want it to do.
The first step in the design process is to put the overall application definition into words. This is usually done by writing a short paragraph describing exactly what the application is and what it will be able to do—for example,
This example presents you with a good idea of what main functions the application will perform, giving you a final goal to aim for as you define the more detailed functions in the application. As an alternative to describing the application in a paragraph, you could list the main functions of the application in an outline format as follows:
This method would also give you a road map to follow when defining the functions in more technical detail. A good method for putting the functional definitions on paper is to describe each function in detail. When doing so, you should try to describe in sequence all the events, options, and results that might occur when users choose this function in the application. You might also describe how this function interacts with other functions in the application. Keeping to a conversational style when describing each function makes it easy to understand what each function will be doing. A definition of a data entry form in this type of style is as follows:
Data Entry. The data-entry form will allow entry of the following information: name, address(es), phone number(s), spouse, child names and ages, and other miscellaneous information about the person being added.
This function must allow for as many different addresses, phone numbers, family members, and miscellaneous information as needed. The number can vary from entry to entry. It will also check if the input is correct (that is, validate that the phone number has the appropriate number of digits). Also, it will verify that the person being added isn't already in the database. Finally, a modification and delete function will be supported.
New Term
As you can see in this example, the main function is broken into subfunctions, which describe each step within the main function, such as what the application will do when the entry form's Update button is clicked.
New Term
The next step in the design process is taking these functional definitions and translating them into a technical definition or pseudocode. Pseudocode is a style and a technique that allows you to define a function in such great detail that you can almost write the Visual Basic code from the pseudocode. The problem with the technique is that it's not as easy as it sounds because most of us don't think like a computer. When you force yourself to create the pseudocode, however, you'll find that many technical issues that you didn't think of are discovered and added to the design or removed from the application. The following simple function demonstrates how pseudocode would look:
Duplicate Name Check Input: Name of person being added to database. Process: Get input name Initialize SQL statement to query the database for the input name Execute the SQL statement Check the query resultset If no records are found – return a 0 to signal that no duplicate records were found If a record was found – return a 1 to signal that the entry is a duplicate Close the query Exit function Error Process: If an error occurs Display the error number and message to the user Return the error number to indicate a problem occurred while checking the database
As you can see, because this is almost Visual Basic code by itself, translating it into actual Visual Basic code will be far easier than if you didn't do this type of designing.
Finally, you need to define the forms and reports you'll need according to the functions already defined. This is more difficult to do because there's really no set way of doing this type of design. You'll find many tips, concepts, and suggestions about form design (as covered later in this book); however, it really comes down to personal choice on how the forms will look.
With all that said, remember that the design you finally come up with isn't set in concrete. You can and should go back over the design several times, looking for possible problems before you start creating the actual application. This critical review of your plans is an important part of the design process.
Coding
Well, you've done it. You made it past the design phase of your project. Be proud that you did; more than half of all application projects never make it this far. Now you're ready to start coding, but don't bite off more than you can work on at one time. Also, treat the coding process like you're peeling an orange. Start by coding the main form of your application with the menu and button bar in place (see Figure 1.6). When you code your application, start with what the user will see when it's started.
){kind=link}
Figure 1.6 Main form of a sample application showing the skeleton of the user interface.
At this point, if you selected any menu or button options, nothing much would happen because you haven't written any code related to those options. Writing code for the computer isn't as simple as writing a letter. The code placed in a Visual Basic application is organized hierarchically. An application generally consists of one or more modules, including form modules, one for each form in the application; standard modules for shared code; and possibly class modules. Determining which procedures belong in which module depends somewhat on the type of application you're creating.
There are certain ways or conventions for formatting and labeling everything in program code. Coding conventions is an attempt to standardize the structure and coding style of any application so that you and more importantly others can easily read, understand, and maintain the code. Because most applications aren't as simple as the "Hello World" example most books use to teach programming, the organization or structure of your application code becomes very important. Depending on what a section of code does and where it's used, you would place it in different areas of your application. Code is placed in three areas:
Event procedures are subprograms coded to execute in response to specific events in your application.
Standard code modules are subprograms not related to a specific form or control that might be used by objects in different forms.
Class modules contain code and data.
By structuring your code properly and following good coding conventions, your source code would be more precise, readable, unambiguous, and as intuitive as possible.
NOTE
The object of conventions is to make the application code easy to read and understand without inhibiting your natural creativity with excessive constraints and arbitrary restrictions. For this reason, the conventions suggested here are short and entirely voluntary. This section isn't attempting to tell you how your coding should look or be done; it's only making some suggestions.
Listing 1.1 is a before example of a coded function.
Listing 1.1 Hard-to-Read Code
Private Sub save_but_Click()
Me.Cursor = System.Windows.Forms.Cursors.WaitCursor
noupd_ent = False
If new_but.Enabled = False Then
Set logset = logdb.CreateDynaset("cdt_tbl")
logset.FindFirst "[first name] = '" & fname.Text & "' and [last name] =_
'" & lname.Text & "'"
If Not logset.NoMatch Then
logset.Close
noupd_ent = True
Me.Cursor = System.Windows.Forms.Cursors.Default
MsgBox("Duplicate Candidate Name Entered")
fname.SetFocus
Exit Sub
End If
logset.Close
End If
If data1.Recordset.EOF And data1.Recordset.BOF Then
norecs = True
Else
bk = data1.Recordset.BookMark
norecs = False
End If
If Len(lname.Text) = 0 Then
Me.Cursor = System.Windows.Forms.Cursors.Default
MsgBox("You Must Enter a First and Last Name.", 32, setmsg)
Exit Sub
End If
data1.Recordset.Update
loading = True
cdt_sel = data1.Recordset.Fields("cdt_id").Value
noupd_ent = False
Me.Cursor = System.Windows.Forms.Cursors.Default
End Sub
When you enter code, the two easiest things that you can do are add comments to the code and consistently indent the code so that different logic blocks become obvious (for example, If...Then...Else...End If). Both conventions improve the overall readability of your code. To further the trend of commenting your application, you should have a brief comment box at the beginning of each procedure and function to describe what the item does (but not how). Any arguments passed to the procedure should be described when their usage isn't obvious or when a certain range of values is expected.
You've probably also read about the need for naming conventions. In a Visual Basic application, every object, constant, and variable needs to have a well-thought-out name. Each name should include a prefix that defines the data type it's defined as. For example, strFirstname tells any programmer that the variable is defined as a string and that it's used to hold the first name for a data entry.
To show you how all this helps, the earlier sample code has been rewritten with all these conventions (see Listing 1.2).
Listing 1.2 Properly Formatted Code for Easy Reading
Private Sub cmdSaveRecord_Click()
'********
'* This routine will check to see if the person being added to
'* the database is already there. If it is not on the database then
'* it will complete the ADDNEW function by issuing an UPDATE against
'* the database.
'*
'* The variable vntBookMrk is used to pass the pointer to the current
'* record. The variable intNoRecords is used to inform the calling routine
'* if the Record was found or not.
'*
'*********
Me.Cursor = System.Windows.Forms.Cursors.WaitCursor
'* If this is a new entry check to see if it already exists
If cmdNewEntry.Enabled = False Then
Set recLogRecord = dbLogBook.CreateDynaset("cdt_tbl")
recLogRecord.FindFirst "[first name] = '" & txtFirstName & _
"' and [last name] = '" & txtLastName & "'"
If Not recLogRecord.NoMatch Then
recLogRecord.Close
Me.Cursor = System.Windows.Forms.Cursors.Default
MsgBox("Duplicate Candidate Name Entered", _
VBExclamation, Form1.ActiveForm.Text)
txtFirstName.SetFocus
Exit Sub
End If
recLogRecord.Close
End If
'* If no records were found set intNoRecords to True
If datLogEntry.Recordset.EOF And datLogEntry.Recordset.BOF Then
intNoRecords = True
Else
vntBookMrk = datLogEntry.Recordset.BookMark
intNoRecords = False
End If
'* If the last name was not entered then display an error message
'* to the user and exit the routine
If Len(txtLastName) = 0 Then
Me.Cursor = System.Windows.Forms.Cursors.Default
MsgBox("You Must Enter a First and Last Name.", _
VBExclamation, Form1.ActiveForm.Text)
Exit Sub
End If
'* if you got this far update the record.
datLogEntry.Recordset.Update
intEntryKey = datLogEntry.Recordset.Fields("cdt_id").Value
Me.Cursor = System.Windows.Forms.Cursors.Default
End Sub
As you can see from this final version of the routine, the code becomes very easy to follow. Related If...End If statements are easy to spot, and the comment box explains the routine's overall purpose.
New Term
In the routine, notice that two variables are Public—meaning that they were defined outside the routine. The scope of your objects, constants, and variables are important. They should always be defined with the smallest scope possible. Global variables can make the logic of an application extremely difficult to follow. They also make it much more difficult to reuse functions or subprograms in other applications. The concept of scoping is covered later in this book.
Testing and Debugging\
New Term
After you start coding your application, you need to start the process of testing the code to see whether it works and to fix or debug the code that doesn't. Not everyone tests as thoroughly as they should; this is attested to all the fixes and upgrades to existing software. Then again, no matter how much you test, there will always be bugs that you didn't find. In addition to bugs that you didn't find in the first place are bugs introduced into an application whenever changes or other fixes are applied to the code. To prevent much of these types of bugs, you should do what's called regression testing—retesting everything that has been tested before.
You'll actually be doing two levels of testing:
Unit testing. Testing individual routines or sections of code. An example of this would be to test just the code for the data-entry routine and nothing else.
Integration testing. Testing all the different units as a single system.
When testing your application, try not to use data or input that you know will work. The real art in testing is to pick test data that most likely will cause errors. You also can try the "what-if" method: Ask yourself what would happen if the user does something unexpected, such as enter letters in a phone number text box. After you begin testing your code, errors will show themselves.
The other half of this team, debugging, is the process of identifying the cause of an error and correcting it. (Testing, on the other hand, is the process of detecting the error when it occurs.) On some projects, debugging occupies as much as half of the total development time and, for many programmers, is the hardest part of programming.
The testing and debugging process is a long and arduous task; however, Visual Basic comes with some great tools to help you test and debug your application code. On Day 14, "Testing and Debugging the Application," you'll see how to use all these tools. One thing that you must pay close attention to is the usability of the forms that you create for your application. Making sure that the application you've created is intuitive to use is part of the total testing process.
Documentation
It doesn't matter how great your forms are; sometimes users will need help. A help system for an application should include online help and a user's manual; it might also contain other features, such as ToolTips, status bars, What's This help, and wizards.
NOTE
The software industry has been moving away from the old-style printed user manuals and have replaced them with either an HTML or PDF electronic format.
Online help is important for any application—it's usually the first place users go when they're having problems or have questions. Even a simple application should provide some type of help; not providing help assumes that your users will never have any questions.
Conceptual documentation, whether printed or provided in electronic format such as a Word document, is helpful for all but the simplest applications and can provide information that might be difficult to convey in the shorter help topics. At the very least, you should provide documentation in the form of a ReadMe text file that users could print out if desired.