Accessing control properties from a module subroutine

[Simon]

Hello,

I have been working with Visual Basic for a couple of years and recently I bought Visual Basic .NET. Ive managed pretty good with my experiences from Visual Basic 3.0, but sometimes I just dont know what to do , and the documentation doesnt help me at all.

My question is simple:
From a module I want to access the properties of a textbox on a form. Is this the correct syntax:

formname.textbox.Text = ""

This doesnt work. VB says:
"Reference to a non-shared member requires an object reference"

How do i share the member?
How do I make an object reference to my textbox?

Regards,
SiMoN.

 

[Cywizz]

Try this thread:
http://www.computerhelp.forum/showthread.php?s=&threadid=49831

 

[Heiko]

Modules are bad.

Modules are not good for the object-oriented programmer.

Modules hinder you from "thinking in an object oriented manner".

 

[CaNaDiAn BaCoN]

Accessing Forms from Modules

Unlike VB 3-6 forms are not static (or "Shared") objects, meaning you have to create an instance first!

I agree with Heiko, but there are some cases where modules are the best option so the easiest way to fix your problem (assuming the form is called MyForm) is

1. Add this code to your module

Module myModule
     Public theForm as New MyForm Add this line

2. Create a Sub Main inside your module and put the following code inside it

Public Sub Main()
     theForm.Show()
End Sub

3. Now change your projects properties so that the startup object is "Sub Main"
4. You should be able to reference controls on that form through theForm, from ANY module (Although you may have to type myModule.theForm)

 

[Simon]

I just read the chapter "Your first OOP" in the sample chapters book that followed Visual Basic .NET Standard.
Now I understand what a class is, good work Microsoft!

I realizes that my application doesnt need a module and thus the problem solved itself. The reason why I created a module in the first place was because I wanted a way of grouping my procedures.
Since Ive used VB3 and VB5 for a long time I tend to make procedures and functions for almost every code that can be used by other procedures (rather than writing the same code twice)

I wonder, is this good .NET programming, having so many procedures, or is it something that better belongs to VB 3-6?

(Ive tried using the classes, but unfortunately, the application Im working on now doesnt require more than one class )

Regards,
SiMoN.

 

[Nerseus]

"global" classes can have their uses for reuse. They can do anything you need, but combing a few lines of code into a function can make your work a little easier. In C# (in VB, too), you can declare classes with static/shared members that are the equivalent of modules in VB6 and earlier.

For instance, I had the need to calculate the number of months between two dates. I use it in many places so it doesnt really belong as a method of a particular class. Plus, I dont want to have to instantiate an object just to use the function. Heres how I did it in C#:

public sealed class DateFuncs
{
	// Private constructor - cant create class
	private DateFuncs() { }

	public static int MonthDiff(DateTime startDate, DateTime endDate)
	{
		return ((endDate.Year - startDate.Year) * 12) + (endDate.Month - startDate.Month);
	}

I chose to make the class sealed (cant inherit from it) and the constructor is private so no one can instantiate it. Marking the method as static means I can use it with:

    int diff = DateFuncs.MonthDiff(date1, date2);

Just about every type of code has its uses, even modules. I think the consensus is that a module isnt necessarily going to be around forever but the equivalent "global" type of functions are still of use, just work differently in .NET. Just a matter of learning what to use instead

-Nerseus