[RESOLVED] Undestanding the use of Controls

[MrPumper]

I have this code that someone from this forum showed me how to use.

Dim theText As String
For j = 1 To 10 Step 1
            theText = Controls("txtScore" & j).Text
            If theText <> String.Empty Then X = X + 1
        Next j

It is in a Private sub located in Form1.vb
It works as expected.

I move the sub to a Module I named FileIO.
It says Controls is not declared and gives BC30451, can anyone tell me what is going on without ripping me a new one saying
I need to read more etc. I am trying to do just that

I have been trying to find out about "Controls" I press F1 when the cursor is over "Controls". It sends me to a nice Microsoft
description that a new user like me has no idea what it is saying(typical Microsoft)

I really would like to learn but I need your help.

[OptionBase1]

Short answer - the code works when the code is located inside of your Form's code because the Controls also exist inside of your Form.

The code doesn't work when the code is located inside of your Module because the Controls it is trying to interact with aren't located inside of your Module, they are located inside of your Form.

[MrPumper]

Thanks OptionBase1, I suspected something like that so I thought if I add Form1. like this

theText = Controls("Form1.txtScore" & j).Text

But it did not work??

[OptionBase1]

I believe the correct format would be*:

Form1.Controls("txtScore" & j).Text

*Note that results might vary. Read about "Default form instances" for more information.

[OptionBase1]

I'll note that new programmers seem to want to put a bunch of code in a Module. There's really no good reason to do that if the code is written specifically for one particular form to perform functions with it. As you are encountering, it ends up causing problems that are easily avoided by simply keeping the code inside of the form itself.

[MrPumper]

Thanks OptionBase1, I have done that and I see what you mean.
As a guide, when should one look to putting code in a Module?

[Shaggy Hiker]

I'd start out with "never", and then break that rule as needs arise.

The thing to understand is classes. Everything in .NET is a class. Your form is a class, a module is a class, controls are classes, everything is a class. A form is nothing special, at least not under the hood. Some of it is slightly hidden from you, which is kind of special, and it works with the designer, which is also kind of special, but as code, it isn't special. You could create a form entirely in code, without using the designer even a little bit, if you wanted to. Obviously, the designer is FAR easier, but it is just there because it is far easier, not because it is essential.

If you understand classes, then you realize that they have members. Your Form has members, as well, and the Controls collection is a member of your form class. You can access it within the form, because any method in a class can access all the members of the class. You can't access it outside of the class, because code outside of the class doesn't know about code specific to the class. Therefore, when you say Form1.Controls, you are saying "the Controls member of Form1", so the code knows what you mean when you type Controls.

Having said that, you should be aware that Form1.Controls doesn't mean "the Controls member of any instance of Form1 that happens to exist." Instead, it means the Controls member of a very specific instance of Form1, the default instance, which may not be the one that you are looking at one the screen. If you want to work with the default instance, then Form1.Controls will work. If you want to work with any other instance, which is far more likely, then Form1.Controls will not work, because it will be using just the default instance.

The default instance is essentially a form instance with the same name as the form itself, so you can think of it as being this line of code located in a Module:

Public Form1 As New Form1

That isn't quite what happens, as VS is more efficient than that, but that's close enough. When you access the default instance, if it doesn't exist, a new instance just like what is shown, is created. It's an instance where the name of the variable is the same as the name of the type.

You may also want to take a look at the .designer.vb file associated with the form. What you will see in there is just code, which you could write yourself, but the designer has saved you the time by writing it for you. You will see all the controls being declared, and a method called InitializeComponents, which is the first thing called in Sub New(). Inside InitializeComponents, you will see all the controls being created, all of them being added to .Controls collections of either the form, or some control on the form, and you will see all the properties for the controls being set. You can also see how very tedious it would be to have to write all of that yourself.

So, what is a module? It's a class, just like everything else. You never need to use a module, because you can create a class that works almost exactly the same. A module is a class where all the members (methods and variables) are Shared. You don't have to write Shared for each of them, calling it a module takes care of that. If you created a class and put Shared on ALL the members, then that class would be the same as a module. The problem with that is that to access any member of that class, you'd have to give the class name:

Public Class Foo
 Public Shared Sub Bar()
End Class

'To use it:
Foo.Bar()

A module is slightly simpler:

Public Module Foo
 Public Sub Bar()
End Module

'To use it"

Bar()

So, a module allows you to skip writing Shared for all the members, because it is done for you, and you don't have to use the module name explicitly to refence a member. Those are just syntactical sugar bits added for VB to make it act more like VB6. Under the hood, the module Foo is the same as the class Foo.

So, what use are modules? Not all that much, really. They are useful if you want some variable that every form and class should have access to, but such global variables have to be used with great caution, because they can create horrible spaghetti code if used unwisely. You would also want a method in a module if the method will be:

1) Used by many parts of the code.

2) Makes use of nothing but global variables.


Those two requirements are hard to meet in most programs. For example, you are using the Controls collection, which is not a global variable, but specific to forms and controls (controls all have Controls collections). Is there really code that you would want to use with ANY form? Every form is likely to have different types of controls with different names, so it is quite rare to have a method that would apply to EVERY form. If such a case does exist, then you can pass the form in as an argument:

Public Sub Bar(someForm As Form)
 someForm.Controls() 'etc.
End Sub

But it is so very rare that there is almost always going to be a better design.

So when should you use a module? Start with never, then break the rule as necessary.

[MrPumper]

Thanks Shaggy Hiker, I have copied your explanation so I can bring it up and read every time I write or change a program.

Thanks also to OptionBase1 for your help as well.

[MrPumper]

Can you help me understand this:

txtDate2.Text = txtDate1.Text
        txtScore2.Text = txtScore1.Text
        txtCourse2.Text = txtCourse1.Text
        txtPlayDayIndex2.Text = txtPlayDayIndex1.Text

        txtDate1.Text = txtDate0.Text
        txtScore1.Text = Me.txtScore0.Text
        txtCourse1.Text = Me.txtCourse0.Text
        txtPlayDayIndex1.Text = txtPlayDayIndex0.Text

        txtDate0.Text = ""
        Me.txtScore0.Text = ""
        Me.txtCourse0.Text = ""
        txtPlayDayIndex0.Text = ""

In this sample code that is in Form1.vb, there are 4 places that have to have the Me. added. I can't figure out why?

[Delaney]

Usually, the Me. is optional in the code. What is the error if you remove the Me. ?

that's may be because you use the same text as variable name. Do you have variables called txtScore0, txtCourse0

[MrPumper]

ERROR CODE: BC30456 "TEXT is not member of string

This may be the cause, I call a sub with these in the call
Private Sub CalculatePlayDayIndex(txtCourse0 As String, txtScore0 As String)
I guess that's making them a variable.

[OptionBase1]

Private Sub CalculatePlayDayIndex(txtCourse0 As String, txtScore0 As String)

Yeah, don't do that. If txtCourse0 and txtScore0 are TextBoxes, then I'm not sure what your end goal was with that method declaration.

This is also a great example of why posting lines of code without the context of the method declaration doesn't paint the whole picture and prevents the people here trying to help from being able to do so effectively.

[Delaney]

That's the cause .
when you write

Private Sub CalculatePlayDayIndex(txtCourse0 As String, txtScore0 As String)

, you create 2 local variables that are in conflict with you textbox names. So you have to precise that they are controls with the Me.

I recommend you as a rule for the name of the controls, start with the type, then give a name:

button -> B_xxxxx
textbox -> TB_xxxxxx
label -> L_xxxxx
datagridview -> DGV_xxxxxx
etc...

[MrPumper]

I was using it like this:

If txtDate0.Text = "" And Me.txtScore0.Text = "" And Me.txtCourse0.Text = "" Then
            MessageBox.Show("NO Data Entered", "Data Entry")
            Exit Sub
        End If

After discussing things with you I saw I did not need to call the sub with those identified with "As String" the Text boxes was all I needed.
I call the sub without any variables passed.

Now the Me. is not needed. After your response was I using those as variables sent me in the correct direction.

Thanks for your response.