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..