VB.net how to access class variables from a form the class opens/calls.

Question

1.00/5 (1 vote)

See more:

I have created a class in vb.net, it performs a bunch of functions on an array. I open a form and display a number of items that are part of the class that opened it. How do I access the class that called it's variables and functions to perform anything? I tried Me.Parent, Me.Owner, ... no luck? I have included the calling subroutine of the calling class below. There are other functions in the calling class I would like to access from the form's buttons. The MachineLogForm is created previously and is simply included as a form in the IDE.

Would appreciate any help.

Thanks, Makulais

''''''''''''calling class''''''''''''''''''''''

VB

Public Class MyClass
Public Sub DisplayCurrentMessages()
       Dim mylogdisplay As New MachineLogForm
       mylogdisplay.ShowDialog()
End Sub
    'do some work here on data displayed in mylogdisplay
Public Sub AnotherFunction

End Sub

''''''''''''''''code from form that mylogdisplay is created from'''''''''''''''''

VB

Imports System.Windows.Forms
Public Class MachineLogForm
    Private Sub pbClearAll_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles pbClearAll.Click
    ''''at this point i want to call AnotherFunction from the instance of the
    '''' class that opened this instance of the form
    '???????????????????????????????????????????????????????
    End Sub
End Class

Posted 4-Mar-12 6:00am

Makulais

Updated 4-Mar-12 6:07am

Uday P.Singh

v2

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Dave Kreskowiak · Answer 1 · 2012-03-04T07:33:00

Solution 1

You can't do that. Since the form has no idea what class instance called it, there's no way for you to call back to a method in that type.

This would also tie both forms together so neither could be used again without the other form.

It sounds as though your app design is a bit messed up and you need to reevaluate each forms responsibilities and possibly redesign your data model.

If your form is manipulating data, it really shouldn't be. Encapsulate the data and all the methods to manipulate it in it's own class. Then each form can tell the data class what to do without relying on the other form.

Forms should handle UI functions and command a data model to do what needs to be done, nothing else.

Posted 4-Mar-12 7:33am

Dave Kreskowiak

Updated 4-Mar-12 7:34am

v2

Comments

Sergey Alexandrovich Kryukov 4-Mar-12 13:39pm

Very good points, a 5.
OP is recommended to accept this answer formally (green button).
--SA

Manfred Rudolf Bihy 17-Mar-12 15:09pm

Moved on OP's behalf from non-solution

I understand your points, and it is written that way, the data is all encapsulated and all the methods are also. but i also wanted a display function to be part of the class so that i can reuse it with different instances as a method call from the class. when the method of the class displayed it's data, in that display would be a button to reset the data from the instance of the class that is being displayed.

I would have to say also that my example above may have oversimplified the actual code. And to my knowledge, the opened form does know which instance of the class called it, it can access that information by 'Owner', it just doesn't know or have access to any of 'Owner' subroutines, methods, or variables at design time.

i don't really think that the app design is messed up from the aspect of encapsulation, maybe the fact that i want a self-contained display is so that i don't have to rewrite code outside of the class to display and reset it's data? but that only seems like common-sense to me.

anyway, to accomplish my goals i used the DialogResult and passed back a value that told it to reset the data and then reopened the dialog immediately. There is a slight blink, during the redraw when the dialog/display actually closes and reopens, but it works. I was hoping to get a 'cleaner' way to do it. If someone else has one, by all means, please chime in.

Dave Kreskowiak 17-Mar-12 19:19pm

but i also wanted a display function to be part of the class

The class does NOTHING but handle the data. Any display garbage violates the rules of encapsulation. If you want the class to display something, you don't display it. You create events that the consumer (your UI code) can subscribe to and get notified of changes or updates. Your data class is allowed to raise events, not make calls into something it has no business calling.

in that display would be a button to reset the data from the instance of the class that is being displayed
Easy enough. Your UI code (form) puts up the button and, when the button is clicked, it can call a method in your data class to reset it.

i don't really think that the app design is messed up from the aspect of encapsulation

Oh, yes it is! If you want to mix business and UI in the same class, it's seriously messed up.

maybe the fact that i want a self-contained display is so that i don't have to rewrite code outside of the class to display and reset it's data

That's just being lazy and the result of a bad degin approach to begin with.

Makulais 17-Mar-12 19:22pm

After thinking about it a little more, I would have to say that the correct way to implement what I need is to create another class that holds both the forms needed, and the data class, that way i would be able to work through it to handle the information exchange and still have all the code wrapped up in one neat package. I'll call this solved on my own.

Dave Kreskowiak 17-Mar-12 21:22pm

If you get this to work it'll be the ugliest solution.

Makulais 18-Mar-12 10:25am

then i guess i wasn't really clear about my ultimate goal and instead was pursuing a question that would lead to albeit down a path that violated the rules of encapsulation coding etiquette or whatever.

my goal is a self-contained piece of code that is easily re-used in a new program. i thought by putting the UI in the class i could accomplish that goal, therefore the desire to manipulate the data from inside it.

I can move the UI back out of the class and easily keep it separate, it already calls the method to clear the data anyway, but what would be the correct way to 'wrap' it all up into one piece of code so that can be re-used in a new program easily?

Makulais 18-Mar-12 10:29am

wouldn't what i did in the final, (read the solution i posted) be considered an object-oriented wrapper with the data and UI in separate internal classes? Is that the 'correct' approach?

Makulais 18-Mar-12 11:04am

What's the difference between what i did, and a program? the application is the wrapper class, then you have forms (UI) as separate classes inside it, and you would also have data classes inside it. the data objects and forms objects are instantiated inside the application object, the forms pass information to the application which then calls methods/properties of the data class? that's what i did, it's just not an entire program. I've seen wrapper classes like this all the time, how is mine any different? why is it 'ugly'? wouldn't all windows forms applications then be 'ugly' and a bad design approach?