Adding user-controls dynamically

As promised, I'm going to teach you how to add user-controls to form dynamically. If you haven't seen the previous article on adding intrinsic controls, then I suggest you read it first so you can appreciate this even better.

Although it's ideally better to apply this to ActiveX OCX, we can still do this on an ordinary standalone EXE project.

Since we'll be adding user-controls, we need to create one first. So add one from the project window (see screenshot below):

Next, let's rename this as "MyControl". You can use a different name but make you use that name when copying the codes later on.

Then we'll just make a simple design, add a Label and a Textbox to our user control.

I changed the background color to easily distinguish the control from the form that it will be added on to (but this is not required).

A. I just changed the Labels caption to "My Control". Again, you can change this to anything you like.

B. This is the textbox so we can do something to it other than making it appear on a form

To make our user control interactive, we need to broadcast some events to the consumer (the form in this lesson).

So let's add two(2) events:

Clicked() - we'll fire this event when the user clicks on the user control

KeyPressed() - we'll raise this when the user types something on the textbox

So copy the code shown below to the user control:

Next we define when these events will fire. First, let's work on the Clicked event by double-clicking on the user control (or go to UserControl object and Click property).

You should see a code similar below:

And for the KeyPressed event, we'll raise it when the textbox changes (see below):

Okay, our user control is now ready for testing. We need a consumer so we'll just use the default form in the project (see below):

In the previous post, we used an intrinsic or built-in data type called TextBox (which is specifically for a textbox control).

For user controls, VBControlExtender will be the data type to be used.

So let's define a variable of that type (with events). See below:

We don't always need it but to give you the full benefits, I'm always suggesting you create the variable as "withevents" so we can capture and handle events.

And if you've read and tried my previous post, the next codes will look familiar.

We still added the user control on the forms controls collection and given it a name (Input01) and then showed it by making it visible.

So what's the difference? Well, since VB can't possibly predict every possible user control a user can create and also the events it would contain, event handling is the main difference between intrinsic and user controls.

Remember in the previous post that we handled a specific textbox event (Change). If we created a CommandButton, there is no Change event but we could have handled the Click event.

So the more intrinsic control type you add dynamically, the more event handling you need to code.

So if that does not sound good to you, user-control could be your alternative.

And to handle user-control events we go the ControlExtenders ObjectEvent event (see below):

This event provides an Info object parameter.

It contains two(2) basic properties --- "Name" and "EventParameters".

1. Name is just a string containing the controls name.
2. EventParameters is a collection object having two(2) properties:

• Name - refers to the parameter name
• Value - refers to the paramete value

It's hard to picture I know, so let's see it in action.

Run the application and type something on the textbox (example, type lowercase a):

You should see a message similar below:

This is because we fired the KeyPressed event on the Text1_Change event, remember?

Now this "KeyPressed" refers to the Info.Name I was telling awhile ago.

Click on the "OK" button and another prompt will show:

Okay, this contains two(2) information:

• The "97" is the Info.Parameters(0).Value
• The "KeyAscii" on the title/caption is the Info.Parameters(0).Name.

Now you get what I was saying, right? :)

Finally the letter "a" appeared on the control (as expected).

Remember I said something about changing the user control background?

For the next test, we'll click on the user control and see if the Clicked event will fire.

If you did not change the color of the user control, just try clicking near the textbox.

As soon as you clicked the control, a message will appear (just as expected)

This time, the Info.Name is "Clicked" (the previous one is "KeyPressed" just in case you forgot).

Since Clicked has no parameter, there is no other message that will appear (unlike in KeyPressed where KeyAscii and 97 appeared).

Okay that's it! You now have two(2) methods of adding controls at runtime on a form.

Hope you liked it and enjoyed working on it. Thanks for reading!

Adding controls dynamically

We almost always put controls on our form during design time. That's what we learned when we first learned VB6 and that's what all of us usually do when writing software applications.

But there is another way to put controls on a form --- during execution time.

Although this technique might not be applicable to you now, it's better to know it just in case you encounter a requirement that requires something like this.

As usual we start off with a blank project and a default form is created for us.

Don't worry about this being "Form2" instead of Form1. It doesn't matter what form you use it on.

Make sure there's nothing on the form (see screenshot below):

Double-click on the form or click the "View Code" on the project window so we can enter the codes needed to create controls dynamically.

Copy the codes shown in the screenshot below:

You can skip writing the comments so it won't be tedious. I just put them there to guide you.

So what the code above means is basically we defined a "with events" textbox control variable.

Then we add it dynamically to the forms control (Controls.Add).

The 1st parameter is the control to be created. In this case it's VB.TextBox

The 2nd parameter is the name you want to give to this control (i.e. MyText)

After adding our textbox to the forms control, it's not automatically visible so we have to tell VB to show it (mtxtDynamic.Visible = True)

And lastly just to prove that it is our dynamically added textbox, we just display it's name using MsgBox.

Run the project and you should see a message similar below:

A. This is the default project name (Project1)

B. This is the name of the textbox we created

And when you click the "OK" button, the form will be shown with our textbox.

If you want to move it somewhere else, just set the Left and Top of it, set the width and height to set a different size, etc.

Now we'll trap or handle one of the textboxs events : Change. You can choose any event you want but for this lesson, I'll just use this.

Enter the code similar to the screenshot below:

When you run the project, type something to the textbox we created. The form title or caption would reflect whatever you type in it. (see below):

Well that's it for now. Next time, I'll show you how to create dynamic user-controls. Yes, the one you create and not those built-in controls.

Coding Standard

In this tutorial series, we will cover the proper or recommended ways of coding.  Although this tutorial is specific to Visual Basic 6.0, you can implement the idea in any language you use.

Note that all instances of the word Visual Basic refers to the classic, not VB.Net.

Visual Basic allows programmers to create applications in the shortest possible time.  That’s why it is considered or classified as RAD tool where RAD stands for Rapid Application Development.

One of the reasons VB can accomplish that much in a short span of time is that it is not “strict” in terms of declarations and code structures.  This means you can use a variable without declaring it first.  You don’t need explicit statement termination like semicolon (;), no need for open and close curly braces “{“, “}” to begin and end a code block and no indentation rule to follow as well.

Some of the best-known “strict” languages are C++ and Java, which enforces one or more of the coding rules.

But it doesn’t mean we cannot or should not exercise good coding practices when writing VB applications.

 

So when do we apply coding standard and when can we disregard it?

Here are some instances when to and when not to consider coding standard:

Use coding standard when:

Writing big applications like corporate applications

Writing applications with other developers

Writing anything that will be distributed or released and maintained

 

No need to use coding standard when:

Writing prototypes or proof-of-concept application

Testing a business rule or logic

Testing a technique or library or component

Of course all of the standards in the world will be useless if one forgets to implement them.  And one of the most neglected aspects in VB programming is variable declaration.  Sure VB doesn’t mind and like we discussed earlier that it is allowed to use a variable even without declaring it first.

When writing prototypes this is fine.  But when you have to debug thousand lines of codes, this would be a huge problem.

 

The easiest way to make sure you declare all variables before using them is by putting “Option Explicit” at the first line of ALL modules (form, basic, class).  See screenshot below:

Or you can let VB do it for you automatically by going to "Tools -> Options" and checking "require variable declaration" as seen below:

Now let's go to the actual coding standard.  

MODULE PREFIXES

VB has three (3) modules --- Form (*.FRM), Basic (*.BAS) and Class (*.CLS) and we can start from there.

Prefix form modules with "F" (yes, we will also use "frm" later).  So if you have the login form, you can name it "FLogin".

Prefix basic modules with "M" like "MCommon"

Prefix class modules with "C" like "CStudent" (yes, "cls" will also be used later)

CONTROL PREFIXES

Here are some prefixes for the most common controls:

CONTROL PREFIX EXAMPLE

Textbox txt txtUserName

Label lbl lblDescription

ComboBox cbo cboCountries

CommandButton cmd cmdCancel

ListBox lst lstDepartments

Frame fra fraBranches

Note that prefixes are small cased and the actual variable name is camel-cased or at least the first letter is capitalized.

The naming prefix can also be applied to other components like "lvw" for ListView, etc.

Just remember the prefix should indicate what type of control it is.  It might not look that helpful but again, when dealing with thousand lines of code, this prefix convention will mean a lot between beating the deadline or beating yourself to frustration.

PREFIXES BASED ON DATA TYPE

For variables here are some suggestions:

VARIABLE WHAT IT MEANS

intAge Integer data type variable for Age 

strEmpID String data type variable for Employee ID

sngSalary Single data type variable for Salary

blnSuspended Boolean data type variable for Suspended

Now if you want to reference a form or class in your code, now is the time to use "frm" and "cls" as in the example below:

dim frmPrompt as FUserPrompt

dim clsEarth as CPlanet

(See?  I told you we will use "frm" and "cls")

For constants, you simply add "c" in the front.  Here is an example:

CONST csngPi as Single = 3.1416

Based on this, you can come up with the prefix for other data types.  Think of the prefix for data type Double and Object.

ADDITIONAL PREFIX BASED ON SCOPE

Although it's already a big help using prefix on the variables, we also need to know quickly the scope of the varialbe (or constant).

VB and some other languages have three scopes : local, modular and global (or public).

Local variables are those declared under a method (sub, function) and properties.

These variables don't need any additional prefix, see example below:

Private Sub Form_Load()

Dim strParams as String

End Sub

Modular variables are those declared at the modular level (available anywhere within the module).   We can prefix any modular variable with small "m".

See example below:

Option Explicit

Private mintLevel as Integer

Private Sub Form_Load()

mintLevel = 45

End Sub

Global or Public variables are those declared in any module using "Global" or "Public".  Both are supported by VB and they practically are the same in functionality.

Prefix Global variables with small "g" and for Public variables use "p" (see below)

In MCommon.BAS:

Global gstrSessionID as string

In FMain.FRM:

Private Sub Form_Load()

MsgBox gstrSessionID

End Sub

INDENTATION AND SPACING

Equally important is "how" we lay out the codes.  Computers and compilers will have no trouble reading your codes, but how about other programmers?  Or you 2 years from now?   How you write the code will be the key to easy maintenance and code debugging later on so if you don't want debugging to be a nightmare, make sure you code correctly.

Here is a sample of a VB code:

Private Sub Form_Load()

Dim r As Integer

Dim x As Integer

    For x = 1 To 5

r = gr(x, 2)

Debug.Print r

        Next

    MsgBox "done"

End Sub

Private Function gr(a, b)

gr = a * b

End Function

And here is the same code, with prefix, casing,  properly indented and spaced:

Private Sub Form_Load()

    Dim intResult           As Integer

    Dim intLoop             As Integer

    

    For intLoop = 1 To 5

        intResult = GetResult(intLoop, 2)

        Debug.Print intLoop & " x 2 = " & intResult

    Next

    

    MsgBox "Done"

End Sub

Private Function GetResult( _

ByVal intNum1 As Integer, _

ByVal intNum2 As Integer) As Integer

    

    GetResult = intNum1 * intNum2

End Function

Now which code would you like to maintain and work on?  

COMMENTS (but not too much)

We can still do more to make reading the codes easier to understand.  And also another neglegted part in programming is putting sufficient comments.

Private Function ComputeAverage( _

ByVal sngPrelim As Single, _

ByVal sngMidterm As Single, _

ByVal sngFinal As Single) As Single

    '

    ' this function computes the average grade

    ' using prelim, midterm, and final grades

    ' as input

    '

    On Error GoTo ErrorHandler

        

    Dim sngSum          As Single

    Dim sngAverage      As Single

        

    ' compute the sum of the grades first

    sngSum = sngPrelim + sngMidterm + sngFinal

    

    ' divide by three to get the average

    sngAverage = sngSum / 3

    

    ' return the result to caller

    ComputeAverage = sngAverage

    Exit Function

ErrorHandler:

    ' display error message to caller

    MsgBox Err.Description, vbExclamation, "Error on ComputeAverage"

End Function

MODULARIZE OR FOLLOW OOP

Another good practice is to divide the codes into logical groups.   Instead of writing everything in (for example) Form_Load, you can put certain business rules into methods (subs and functions) then call them from the main method.

So instead of writing the codes of "ComputeAverage" (exable above) inside Form_Load, we can just call it from there like this:

Private Sub Form_Load()

    sngAve = ComputeAverage(sngPG, sngMG, sngFG)

End Sub

This approach also provides reusability of codes, meaning you can call the ComputeAverage function in other methods or even in other modules (if global or public).

Extending this idea further is when you use libraries like ActiveX DLL/EXE and OCX.

Another benefit of modularizing codes is that it's easier to make the necessary changes and ensuring that all affected areas are updated properly.  If you "copy + paste" every code logic then when you need to change a part of it, you'll need to make changes to all codes you pasted them.  But by using this approach, the changes made on this would be effective to all calls made to it.

And for OOP (Object-oriented Programming), it doesn't necessarily mean you need to write DLLs or OCXs to implement its principles.  There are three (3) basic rules or principles of OOP and they are: Encapsulation, Inheritance and Polymorphism.  Related to our topic is the first one.

Encapsulation

Data of an object should be private.  External consumers (those that use the object) should have a method or property to affect it's value.  In short, avoid global variables.

Example:

Instead of declaring a global variable called "balance",

Global gsngBalance as Single

We should create a modular variable and a public method to update it:

Private msngBalance as Single

Public Sub Deposit(byval sngAmount as single)

msngBalance = msngBalance + sngAmount

End Sub

The intent is obvious.  You don't want anyone or any application to change the value of balance without the proper business rules.

Trust me, dealing with an application that has tons of global variables is frustrating and makes your coding life miserable.

For beginners this looks like a waste of time or extra work but for those of us who have been there, done that, this is worth the while.  There are more ways to write applications but this covers most of the basic concepts that a good programmer needs to know and apply.

Thanks for reading and happy coding to us all!