communication between classes

[doofy]

This is a conceptualization problem for me regarding how
classes/namespaces share information. I can't really return an
object/value back from a called class to a calling class by directly
naming the calling class instance in the called class, as this violates
object oriented guidelines, as I understand them.

Here's the issue.

I'm creating a custom control which will be a tree view that holds table
and field names from an identified database. I have a tree view as the
main control, with a context menu included. In order to get the
information to fill the tree view, I created a small form within the
custom control project. It shows up as a separate namespace within the
project. I don't know how to pull this into the tree view namespace.

Within the form, there is a list box which allows multiple selections.
When I hit the OK button, I need to pass the selected table names back
to the tree view control.

If these were in the same namespace, I could probably just reference a
private variable that they share, but I don't know how to move that form
into the namespace. It automatically created a new namespace for the form.

The other way, I assume, would be to pass some variable/object by
reference into the form control, then populate that object on closing
the form.

Right now I'm just anticipating using one long string with semi-colon
delimited table names, then parsing this out on the calling side.

Will I run into problems with that issue about not being able to change
strings, but having to create a new one each time? This could be a
problem when operating between namespaces.

Or do I need to use the StringBuilder feature (I've seen this referenced
in VB.NET, not sure about C#).

That's a lot of questions. Any help would be appreciated.

 

[Peter Duniho]

This is a conceptualization problem for me regarding how
classes/namespaces share information. I can't really return an
object/value back from a called class to a calling class by directly
naming the calling class instance in the called class, as this violates
object oriented guidelines, as I understand them.

Here's the issue.

I'm creating a custom control which will be a tree view that holds table
and field names from an identified database. I have a tree view as the
main control, with a context menu included. In order to get the
information to fill the tree view, I created a small form within the
custom control project. It shows up as a separate namespace within the
project. I don't know how to pull this into the tree view namespace.

This particular part of your question is easy, as you do it just as you do
it with any of the other classes not in your calling class's namespace
(i.e. every single .NET class you are using). You use the "using"
statement, or qualify the class name explicitly when you use it (e.g.
"MyNamespace.MyClassName").

Within the form, there is a list box which allows multiple selections.
When I hit the OK button, I need to pass the selected table names back
to the tree view control.

This is really a different question, actually. Here, it's more about the
correct way to expose data entered in the form to the code that displayed
the form. Even if the form were in the same namespace, that question
would exist.

If these were in the same namespace, I could probably just reference a
private variable that they share, but I don't know how to move that form
into the namespace. It automatically created a new namespace for the
form.

How did you create the form? Normally, if you use the designer to add a
new form to your project, it will put the form in the same namespace. Is
the form in its own project as well?

Not that this matters _too_ terribly much. It's just, as you've seen,
more convenient if the form is in the same project/namespace.

As far as referencing a private variable, no...even in the same namespace,
you can't reference a private variable in a different class. But you're
on the right track.

The other way, I assume, would be to pass some variable/object by
reference into the form control, then populate that object on closing
the form.

Passing by reference works only if you stay in the same call. So, if
you've added a method to the form to show it modally, yes...you can pass a
variable by reference to that method, and then when the form is closed,
that method would return having copied the data to the variable passed by
reference.

An alternative would be to provide a property on the form that retrieves
the data. You can either populate a private field when the form is
closed, inside the form class itself, and then return the value held in
the private field, or you can simply have the property get the necessary
data directly from the form's list box. Either would be fine.

Right now I'm just anticipating using one long string with semi-colon
delimited table names, then parsing this out on the calling side.

I would just return an array of strings, but if you really want to return
a single string I suppose you could.

Will I run into problems with that issue about not being able to change
strings, but having to create a new one each time? This could be a
problem when operating between namespaces.

I don't see how the two issues are connected at all. The namespace issue
is simply one of identifying types. It has nothing to do with whether
you'd need to create a new string from an existing one.

Or do I need to use the StringBuilder feature (I've seen this referenced
in VB.NET, not sure about C#).

StringBuilder could in fact be useful if you really want to concatenate
the list box items into a single string. But I think you'd be better of
just passing back an array.

Pete

 

[doofy]

This particular part of your question is easy, as you do it just as you
do it with any of the other classes not in your calling class's
namespace (i.e. every single .NET class you are using). You use the
"using" statement, or qualify the class name explicitly when you use it
(e.g. "MyNamespace.MyClassName").



This is really a different question, actually. Here, it's more about
the correct way to expose data entered in the form to the code that
displayed the form. Even if the form were in the same namespace, that
question would exist.



How did you create the form? Normally, if you use the designer to add
a new form to your project, it will put the form in the same
namespace. Is the form in its own project as well?

Not that this matters _too_ terribly much. It's just, as you've seen,
more convenient if the form is in the same project/namespace.

As far as referencing a private variable, no...even in the same
namespace, you can't reference a private variable in a different
class. But you're on the right track.



Passing by reference works only if you stay in the same call. So, if
you've added a method to the form to show it modally, yes...you can pass
a variable by reference to that method, and then when the form is
closed, that method would return having copied the data to the variable
passed by reference.

An alternative would be to provide a property on the form that
retrieves the data. You can either populate a private field when the
form is closed, inside the form class itself, and then return the value
held in the private field, or you can simply have the property get the
necessary data directly from the form's list box. Either would be fine.



I would just return an array of strings, but if you really want to
return a single string I suppose you could.



I don't see how the two issues are connected at all. The namespace
issue is simply one of identifying types. It has nothing to do with
whether you'd need to create a new string from an existing one.



StringBuilder could in fact be useful if you really want to concatenate
the list box items into a single string. But I think you'd be better
of just passing back an array.

Pete

Thanks for all of this. I need to digest it.