inheritance problem/confusion

  • Thread starter Thread starter vidalsasoon
  • Start date Start date
V

vidalsasoon

Ok, this is the structure of my classes.


" class Global
" |
" -------------------------------------------
" | |
"class SomeForm1 class SomeForm2


Now I declare an int in "Global" and initialize in the main of
Someform1. When I try to access this int from SomeForm2 it ignores the
changes I made to this int from SomeForm1.

What should I do to have a true global variable that can be modified
anywhere and accessed anywhere without having to worry about these
instances?

hope this is clear.
 
vidalsasoon said:
Ok, this is the structure of my classes.


" class Global
" |
" -------------------------------------------
" | |
"class SomeForm1 class SomeForm2


Now I declare an int in "Global" and initialize in the main of
Someform1. When I try to access this int from SomeForm2 it ignores the
changes I made to this int from SomeForm1.

What should I do to have a true global variable that can be modified
anywhere and accessed anywhere without having to worry about these
instances?

hope this is clear.

It isn't entirely clear, because I can't tell if SomeFormN are subclasses or
instances.

Regardless, the way to make a field have the same value among all instances
is to declare it static.
 
I never had a clear idea on why to use static. with that answer it all
makes sense (and works perfectly).

ty
 
The initilization you have done thru the main(or is it the contstructor?) of
SomeForm1. Now this value cannot be accecced from SomeForm2 as SomeForm2 is a
sub class of Gobal not of SomeForm1.

For accessing this value, you need to create an instance of SomeForm1 within
SomeForm2.

I hope you are trying to create instances of SomeForm1 and SomeForm2 and use
the value initialized by SomeForm1 from SomeForm2. Here the int has object
scope, so every instance will have its on copy of int . You need to declare
the int as static if u wana share with all instances.
 
A word of advice: read up on classes and inheritance, and objects and
instantiation. Those two pairs of words refer to two very different
concepts.

I'm not trying to be picky and pedantic. I'm trying to help. Really.
First, once you have the difference between these two concepts clear in
your mind, the quality of your programs will increase dramatically.
Second, once you understand the difference, and use the correct terms
in your posts, you will recieve far swifter and more accurate
responses. In this case, Mike took a guess at what you meant and he
guessed right, however he might just as easily have spun off into a
discussion of base classes and derived properties that had nothing to
do with your problem.

Again, I don't want you to think that I'm being superior. I just want
you to know that understanding the differences between classes and
instances, and inheritance and instantiation, will be a tremendous boon
to you.
 
If Mike Schilling's solution "works perfectly" then you have a
nomenclature problem in your original post.

You need to get a clear idea of the difference between a class (which,
when talking about it in context with its parent class, is sometimes
called a "subclass") an an instance. It's a very, very important
distinction, both in programming and in asking questions here.

I'm not trying to be picky and pedantic; I'm trying to help. Really. If
you master the difference between a class and an instance, and between
inheritance and instantiation, not only will your programming skills
improve dramatically, but when you ask questions here you'll get far
quicker and more accurate answers. In this case, Mike took an educated
guess at what was really going on and guessed correctly. Next time you
may get completely wrong advice because the explanation of the problem
was incorrect.

Anyway, good luck learning C#. It's a great language, and fun to work
in.
 
my problem was object scope. I had incorrectly assumed that objects
declared in the parent would be modifiable throughout all the
subclasses (as if it was declared static).

I'm still getting the hang of OO and the more I learn the more I
realise how logical/beautiful it is :P
 
vidalsasoon said:
my problem was object scope. I had incorrectly assumed that objects
declared in the parent would be modifiable throughout all the
subclasses (as if it was declared static).

I think you do need to learn and practice the correct terminology, because
you still have me puzzled about instances vs. subclasses. I think what
you're saying, in standard terminology, is:

My problem was name scoping. I had incorrectly assumed that fields
declared in a parent class
are modifiable via a reference to a subclass.

The thing is, that's a *correct* assumprion, which is one reason I'm
puzzled. My best guess at your incorrect assumption is:

I had incorrectly assumed that fields declared in a parent class are
common to all instances of subclasses.

This is true only for static fields.

There really isn't space here to explain the concepts and terminology. Any
good beginning book on C# (or Java or C++, for that matter) will explain
both (mod the different terminology C++ uses for fields and methods.)
 
Simply declare a static member. A static member will be available
throughout the namespace in which it is declared.

For instance,

namespace TestStatic
{
public class ClassStaticTest
{
public static int intTemp;
}
public class Class2
{
int temp;
public Class2()
{
ClassStaticTest.intTemp=12;
}
}
}

with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
 
Ravichandran J.V. said:
Simply declare a static member. A static member will be available
throughout the namespace in which it is declared.

Well, a public static member will be available throughout the whole
AppDomain. An internal static member will be available throughout the
whole assembly. Unlike in Java, namespaces have no effect on access -
they're purely there for avoiding name collisions (and making it easier
to find names, of course).
 
Back
Top