Module Failed to read Form's textbox

[ballwah]

Hi,

I've a form in my vb.net named "Form1", I would like to know if I can get a textbox value from this form by using the Module.

Here below is the code of my Module:

Module Module1
Public myForm As New Form1
Function testing()
MsgBox(myForm.TextBox1.Text)
End Function
End Module

Once I click on the buttom in Form1, the above function "testing" will execute. However, even I type something in the textbox after the program runs, the msgbox comes out with blank.
Can anyone tell me if it is work to call a value of form by module?

 

[jmcilhinney]

I'm guessing that the form on which you are pressing the button is not the same object as is referred to in your module. You can have as many Form1 instances as you like. Changing the text in a TextBox of one doesn't affect any of the others. If that was the case then changing the text in a TextBox would affect every TextBox. I suggest that you follow the Start VB.NET link in my signature and read the OO section, plus read the Multiple Forms tutorial in my signature.

 

[ballwah]

Hi jmcilhinney,

Thanks for your reply.
However, I am not sure if I'd understand your meaning. Would you please refer to my attachment and let me know the problem?
Many many thanks!!!

 

[vis781]

ballwah in your module you have this...

Public myForm AsNew Form1

Notice the 'New' kewword. So as far as your module is concerned it's always dealing with a new instance of form1 so that will have know idea about your original form.

I have a attahced an amended version of your form1 and your module with a bit commenting to help along the way. But i do suggest that you take Jmcilhinney's advice and read the tutorial's he suggested.

 

[ImDaFrEaK]

Just a little tip that may help you or not.

Functions are meant to return values and Sub routines are not, in the call Function you have above it should just be a sub routine.

You can keep it a function if you like but it would be wiser to type it like so if you do.

[COLOR=#0000ff]Function[/COLOR][SIZE=2] testing() as MsgBoxResult
Return MsgBox(myForm.TextBox1.Text)
[/SIZE][SIZE=2][COLOR=#0000ff]End[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]Function
[/COLOR][/SIZE]

You will still have the same functionality if you just call it but this way you get the return value as well if needed. I would just change Function to Sub though since that's all you need.

That's just a tip incase you didn't know, don't mean to bother this thread.

 

[jmcilhinney]

As further explanation, which you may no longer need, let me present an analogy. When you design a form in the IDE you are not designing an OBJECT, you are designing a CLASS. Let's imagaine you worked for a car company. If you designed a new car you wouldn't just be creating one car for the whole world. You'd be creating template from which millions of car objects could be created. Your form is the same. You're designing a template from which form objects can be created. Now, if one person gave their car a new paint job, would other drivers be able to look at their car and see that colour? No they wouldn't, because it would only affect that one car. Your form is the same. If you set the text in a TextBox on one instance of your form class, it doesn't mean that every other instance will also show that same text. When you create an object, you must have a reference to that object to be able to get information from it. You cannot simply create a new object of the same type and expect to get information about the first object. If I had a car key but no car, I couldn't expect to just go and get a new car and the old key fit.

 

[cjard]

ahh.. the inherent confusion created by VB's insistence on creating an instance of every form, named identically to the type.. Microsoft really should have tossed some of the legacy stuff out when they created the VB.NET enviroment

bwalah: the form that you see on screen when you press play, and the form that you declare when you say Dim x as New Form1 are very different things, at different locations in memory.

You;d be better off referring to the default instances that VB creates for you with the global keyword:

[COLOR=#0000ff]Module[/COLOR][SIZE=2] Module1[/SIZE]
[SIZE=2][COLOR=lime]'Public[/COLOR][/SIZE][COLOR=lime][SIZE=2] myForm [/SIZE][SIZE=2]As[/SIZE][SIZE=2]New[/SIZE][/COLOR][SIZE=2][COLOR=lime] Form1[/COLOR][/SIZE]
 
[SIZE=2][COLOR=#0000ff] Function[/COLOR][/SIZE][SIZE=2] testing()[/SIZE]
[SIZE=2]     MessageBox.Show([COLOR=blue]Global[/COLOR].Form1.TextBox1.Text)[/SIZE]
[SIZE=2][COLOR=#0000ff] End [/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]Function[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]End [/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]Module[/COLOR][/SIZE]

 

[ballwah]

hey guys...
Many thanks for your sharing...it seems that I need to return to the basic of VB.net = ='
I've read thru the OO artical but I am not sure if I could get the message from there...In fact, I'm working on a program and designed to put all functions under Module (instead of under each win forms), functions include inserting data (from the win form) to the database and I find difficulties in getting the data from the win form by Module. That's why I raised out this question before.
I'm wondering if there's structural problem if I design my program in this way...(i.e. put all the functions under Module), or do I need to pass the text values everytime to the functiom when calling them?

under Module

Function Insert(Byval Customer)

under win form

Insert(tbox_Customer.text)

Besides, it is impossible to assign form's text value in Module?
Thanks again for all of your help!!!

 

[jmcilhinney]

Putting everything in a module is dodgy. It completely defeats the purpose of using an OO language in the first place. Programming objects are essentially the same as objects in real life, so you should think of them that way and treat them that way. There are different types of things in real life and you can having numerous objects of each type. It's the same in OOP. In real life you cannot do anything with an object unless you are able to get hold of it. If I have a ball and you want to throw it, forst of all I have to give it to you. It's basically the same thing in OOP. In order for your module, or any other object, to set the Text property of a form it must first have a reference to that form object. If you were to start your application from a Main method in your module then you could get a reference that way, because the form would be created in the module in the first place. Otherwise, the form is goping to have to pass a reference to itself to the module. It's just like a person introducing themselves to you so that you know they exist. How are you going to affect an object if you don't know it exists?

 

[JohnH]

Maybe ballwah wants to set up a car service shop? A place where you deliver your car and have it serviced.. This is all well if the business runs fine with much customers, but you don't send your car to the shop for every little thing, that's too expensive. If you are the only customer the shop perhaps should be closed down. For those easy service tasks it is maybe better to buy some tools and do it in your own garage.

 

[ImDaFrEaK]

??????????/

lol

 

[vis781]

ballwah, i am completely confused as to what you are asking here, can you in simple terms what you are trying to do. If it's not the best way to do it then we can help you understand why it isn't and then give you some examples on how your idea can be improved upon. You say you want all the functions to be in a module? Thats the bit that has confused me. That module would be huge!! If there are things you still don't understand then ask.

 

[cjard]

hey guys...
Many thanks for your sharing...it seems that I need to return to the basic of VB.net = ='
I've read thru the OO artical but I am not sure if I could get the message from there...In fact, I'm working on a program and designed to put all functions under Module (instead of under each win forms),

That's called procedural programming. I think you need to read a bit more about OO - it really is quite a hard thing to get into initially, because most people never paused to think about the similarities and differnces between a 1 litre bottle of milk and a 2 litre carton of orange juice..

functions include inserting data (from the win form) to the database and I find difficulties in getting the data from the win form by Module.

Why should the module have to go and get the data? If the module was provided with everything it needed to do its job, then it wouldnt have a problem.
To use a analogy like in an internet forum./. If you had a problem and asked me for help, and provided every bit of information I might need to give you the answer, then I would give you the answer.
If you asked me to do something, i would ask you what. Potentially it could become a whole sequence of back and forth as i colelcted the data I needed

Read a little more about the concept of Coupling in your OO book. Coupling is the bad thing to do; to have two or more objects that rely on each other. If one is not in the project, the other fails. Objects should operate as separate entities.. your module that saves to the DB shouldnt even KNOW or care what a Form is because its not guaranteed that youre always going to be using a form as the data source

That's why I raised out this question before.
I'm wondering if there's structural problem if I design my program in this way...

Not really, but modules are guaranteed to be unique in a program - only one will exist so its where you put thread safe code that doesnt need to be present in variations
It's not there so the newbie programmer can bang all his code in and say Module1.MyFunction() simply because they didnt quite understand the concept of making a class that describes an object, then making a new instance of that object.

(i.e. put all the functions under Module), or do I need to pass the text values everytime to the functiom when calling them?

Yes. Whats the difference between giving the function everything it needs to do its work, compared with hoping it will know where to go to ask for all the stuff it needs to do its work?
One is self-contained, succinct and reusable. The other is a mess, in OO terms

Besides, it is impossible to assign form's text value in Module?
Thanks again for all of your help!!!

It's not impossible, but it harks back to the confusion created because a Form is an object, but VB tries to be too helpful and makes a default instance of the object, with exactly the same name as the object name. When you say frmMain.BackColor = White you are setting the backcolor to white of the form that VB created for you, trying to be helpful. You are not calling a static property of a static module frmMain.
This behaviour was present in VB6 too so its probably to help upgrading programmers, but if you want to see the difference more clearly, learn/look at C# instead - it highlights this difference because all C# programs have a Main method in a static class (module), whose job is to make a new instance of the default form and show it..

 

[ballwah]

Hi all,

So...I'll distribute all the function back to its related forms...and now, I would like to know the function of Module...can Module help me when working on the program?

 

[jmcilhinney]

As you've now discovered, if a method or property logically belongs to a class then it should be a member of that class. The only real use for modules these days is a place to put what you would consider utility methods, i.e. methods that do a job but don't really belong to anything other than the application itself. You might also use a module as a plcae to put properties that you require to be global, i.e. available throughout your project. A module could also be used as a place to put a Main method, from which your application starts. With the advent of VB 2005, you don't need a Main method anymore and I, for one, put my global variables (of which I have very few as they should be avoided if possible) in ApplicationEvents.vb file and access them via My.Application. That leaves utility methods as their only real use. This means that you may need one module per application. You could put groups of related utility functions into modules and compile them into a library. The .NET Framework does this with the VB6-style Runtim functions. That's only done so that their behaviour mimics that in VB6 though. If you were to do this yourself it would be preferable to use a class with all Shared members. Classes like System.IO.File are an example of this technique.