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. I've managed pretty good with my experiences from Visual Basic 3.0, but sometimes I just don't know what to do :D, and the documentation doesn't 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 doesn't 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.xtremedotnettalk.com/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 doesn't 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 I've 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?

 

(I've tried using the classes, but unfortunately, the application I'm working on now doesn't 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 doesn't really belong as a method of a particular class. Plus, I don't want to have to instantiate an object just to use the function. Here's how I did it in C#:

public sealed class DateFuncs
{
// Private constructor - can't 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 (can't 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 isn't 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