I noticed something in C# when dealing with custom objects that I found to be a little odd. I am certain it is just a lack of understanding on my part so maybe someone can enlighten me.
If I create a custom object and then I assign that object to the property of another object and the second object modifies the object assigned to it, those changes are reflected in the same class that did the assigning even though nothing is returned.
You want that in English? Here is an example:
class MyProgram
{
static void Main()
{
var myList = new List<string>();
myList.Add("I was added from MyProgram.Main().");
var myObject = new SomeObject();
myObject.MyList = myList;
myObject.DoSomething();
foreach (string s in myList)
Console.WriteLine(s); // This displays both strings.
}
}
public class SomeObject
{
public List<string> MyList { get; set; }
public void DoSomething()
{
this.MyList.Add("I was added from SomeObject.DoSomething()");
}
}
In the above sample I would have thought that, because SomeObject.DoSomething() returns void, this program would only display "I was added from MyProgram.Main().". However, the List<string> in fact contains both that line and "I was added from SomeObject.DoSomething()".
Here is another example. In this example the string remains unchanged. What is the difference and what am I missing?
class MyProgram
{
static void Main()
{
var myString = "I was set in MyProgram.Main()";
var myObject = new SomeObject();
myObject.MyString = myString;
myObject.DoSomething();
Console.WriteLine(myString); // Displays original string.
}
}
public class SomeObject
{
public string MyString { get; set; }
public void DoSomething()
{
this.MyString = "I was set in SomeObject.DoSomething().";
}
}
This program sample ends up displaying "I was set in MyProgram.Main()". After seeing the results of the first sample I would have assumed that the second program would have overwritten the string with "I was set in SomeObject.DoSomething().". I think I must be misunderstanding something.
This isn't odd, or strange. When you create a class, you create reference type. When you pass references to objects around, modifications to the objects they refer to are visible to anyone that holds a reference to that object.
var myList = new List<string>();
myList.Add("I was added from MyProgram.Main().");
var myObject = new SomeObject();
myObject.MyList = myList;
myObject.DoSomething();
So in this block of code, you instantiate a new instance of List<string> and assign a reference to that instance to the variable myList. Then you add "I was added from MyProgram.Main()." to the list referred to by myList. Then you assign a refernce to that same list to myObject.MyList (to be explicit, both myList and myObject.MyList are referring to the same List<string>! Then you invoke myObject.DoSomething() which adds "I was added from SomeObject.DoSomething()" to myObject.MyList. Since both myList and myObject.MyList are referring to the same List<string>, they will both see this modification.
Let's go by way of analogy. I have a piece of paper with a telephone number on it. I photocopy that piece of paper and give it to you. We both have a piece of paper with the same telephone number on it. Now I call up that number and tell the person on the other end of the line to put a banner up on their house that says "I was added from MyProgram.Main()." You call up the person on the other end of the line to put a banner up on their house that says "I was added from SomeObject.DoSomething()". Well, the person who lives at the house that has that telephone number is now going to have two banners outside their house. One that says
I was added from MyProgram.Main().
and another that says
I was added from SomeObject.DoSomething()
Make sense?
Now, in your second example, it's a little trickier.
var myString = "I was set in MyProgram.Main()";
var myObject = new SomeObject();
myObject.MyString = myString;
myObject.DoSomething();
You start by creating a new string whose value is "I was set in MyProgram.Main()" and assign a reference to that string to myString. Then you assign a reference to that same string to myObject.MyString. Again, both myString and myObject.MyString are referring to that same string whose value is "I was set in MyProgram.Main()". But then you invoke myObject.DoSomething which has this interesting line
this.MyString = "I was set in SomeObject.DoSomething().";
Well, now you've created a new string whose value is "I was set in SomeObject.DoSomething()." and assign a reference to that string to myObject.MyString. Note that you never changed the reference that myString holds. So now, myString and myObject.MyString are referring to different strings!
Let's go by analogy again. I have a piece of paper with a web address on it. I photocopy that piece of paper and give it to you. We both have a piece of paper with the same web address on it. You cross out that web address and write down a different address. It doesn't affect what I see on my piece of paper!
Finally, a lot of people in this thread are yammering about the immutability of string. What is going on here has nothing to do with the immutability of string.
It's absolutely correct:
myObject.MyList = myList;
This line assign a reference of myList to the myObject's property.
To prove this this, call GetHashCode() on myList and on myObject.MyList.
we are talking about different pointers to same memory location, if you wish.
Whether or not a method returns something, has nothing to do with what happens inside it.
You seem to be confused regarding what assignment actually means.
Let's start from the beginning.
var myList = new List<string>();
allocates a new List<string> object in memory and puts a reference to it into myList variable.
There is currently just one instance of List<string> created by your code but you can store references to it in different places.
var theSameList = myList;
var sameOldList = myList;
someObject.MyList = myList;
Right now myList, theSameList, sameOldList and someObject.MyList (which is in turn stored in a private field of SomeObject automagically generated by compiler) all refer to the same object.
Have a look at these:
var bob = new Person();
var guyIMetInTheBar = bob;
alice.Daddy = bob;
harry.Uncle = bob;
itDepartment.Head = bob;
There is just one instance of Person, and many references to it.
It's only natural that if our Bob grew a year older, each instance's Age would have increased.
It's the same object.
If a city was renamed, you'd expect all maps to be re-printed with its new name.
You find it strange that
those changes are reflected in the same class that did the assigning
—but wait, changes are not reflected. There's no copying under the hood. They're just there, because it's the same object, and if you change it, wherever you access it from, you access its current state.
So it matters not where you add an item to the list: as long as you're referring to the same list, you'll see the item being added.
As for your second example, I see Jason has already provided you with a much better explanation than I could possibly deliver so I won't go into that.
It will suffice if I say:
Strings are immutable in .NET, you can't modify an instance of string for a variety of reasons.
Even if they were mutable (like List<T> that has its internal state modifiable via methods), in your second example, you're not changing the object, you're changing the reference.
var goodGuy = jack;
alice.Lover = jack;
alice.Lover = mike;
Would alice's change of mood make jack a bad guy? Certainly not.
Similarly, changing myObject.MyString doesn't affect local variable myString. You don't do anything to the string itself (and in fact, you can't).
You are confusing both type of objects.
A List is a List of type string .. which means it can take strings :)
When you call the Add method it adds the string literal to its collection of strings.
At the time you call your DoSomething() method, the same list reference is available to it as the one you had in Main. Hence you could see both strings when you printed in the console.
Don't forget, that your variables are objects too. In the first example, you create a List<> object and assign it to your new object. You only hold a reference to a list, in this case, you now hold two references to the same list.
In the second example you assign a specific string object to your instance.
Alex - you wrote -
In the above sample I would have thought that, because SomeObject.DoSomething() returns void, this program would only display "I was added from MyProgram.Main().". However, the List in fact contains both that line and "I was added from SomeObject.DoSomething()".
This is not the case. The VOID of the function just means the function does not return a value. This has nothing to do with the this.MyList.Add method you are invoking in the DoSomething() method. You do have to references to the same object - myList and the MyList in the SomeObject.
This is how reference types behave and is expected. myList and myObject.MyList are references to the same List object in heap memory.
In the second example strings are immutable and are passed by value, so on the line
myObject.MyString = myString;
The contents of myString are copied to myObject.MyString (i.e. passed by value not by reference)
String is a bit special because it is a reference type and a value type with the special property of immutability (once you have created a string you can't change it only make a new one, but this is somewhat hidden from you by the implementation)
In the first example ... you are working with an mutable objects, and it is always accessed by reerence. All references to MyList in different objects refer to the same thing.
In the other case, strings behave a bit differently. Declaring a string literal (i.e. text between quotes) creates a new instance of a String, completely separated from the original version. You CAN NOT modify a string, just create a new one.
UPDATE
Jason is right, it has nothing to do with String immutability ... but ....
I can't help but think that string immutabiity has its word in here. Not in THIS concrete example, but if SomeObject.DoSomething's code was this : this.MyString += "I was updated in SomeObject.DoSomething()."; , then you would have to explain that new String is created by the "concatenation", and the first string is not updated
Related
So I've got a simple string array. Passed it to a function that reverses its input and then displayed the content of the array. I was expecting the contents of the array to reverse since arrays are passed by reference, but the string array did not change.
string[] words = { "Metal", "Gear", "is", "Awesome!" };
mutateArray(ref words);
foreach (string word in words)
Console.Write(word + " ");
This is my mutateArray function:
public static void mutateArray(ref string[] arr)
{
arr = arr.Reverse().ToArray();
}
I know that the mutateArray method changes to the array will persist once I state that the parameter must be passed in with the keyword ref.
Aren't all arrays passed in by reference by default?
Why do the changes persist when the keyword ref is involved?
What's the difference between passing a reference type (classes, interfaces, array, delegates) by value vs passing them by reference (with the keyword ref)?
The reason this doesn't work how you expect is that Reverse() does not actually reverse the contents of the array in place but rather makes a new list with the reversed contents of the original. That's why it works once you pass the array by reference: then, you're actually replacing the entire original array in the calling method with a new one created in mutateArray.
If you had a method that did the reversing in-place, you could pass in the original array (not using ref), and after the method call, the array would be in reverse order.
All parameters are passed by value by default in C#. For reference types like array, this means the reference is passed by value.
ref causes the variable to be passed by reference into the function. This effectively means the arr parameter in mutateArray is an alias for words in the caller. This is why an assignment to arr results in a change in words after mutateArray has exited.
Passing a reference type by value into a function means a copy of the reference is made. Without the ref modifier, arr in mutateArray is a different variable containing a reference to the same object as words in the caller. Assigning to arr in this case has no effect on words in the caller. Note that you can mutate the array through the shared reference, but arr and words are separate storage locations.
You're confusing a Reference Type with passing by Reference. The ref keyword can be applied to both Value and Reference types. Even Reference types aren't passed by reference by default. Instead the reference is passed by value to the method.
Based on the documentation from MSDN, they should. That's the whole purpose of using the ref keyword with a Reference Type.
The difference is that when you pass by Reference Type by Reference, you are able to change the reference of the original variable rather than just the instance inside your method. Check the previously linked documentation for more details.
words is a reference to an array. Just consider it to contain the memory address of that array.
When you give it to MutateArray as a parameter (without the ref keyword) its VALUE will be copied into arr. So arr is a different variable as words, but they contain the same value (= memory address). This means that they refer to the same object (the string array).
You can change the contents of the object, but words (and arr) will still be referring to it.
If you assign arr to a different object, then its value changes, so it will refer to a different object than words.
However, if you use the ref keyword, then arr and words are the SAME variable. That means if you change arr's value (= assign it to a new object), you are also changing words's value, so words will refer to the same, new, object.
Maybe all of this is not technically 100% correct, but it's the way I like to think about it in order to understand how it works.
The ref keyword is why the following Swap method works in C#; without it, it would just change the inner variables of the Swap method (and do nothing basicallly)
public void Swap<T>(ref T a, ref T b) {
T temp = a;
a = b;
b = temp;
}
Your question is totally understandable and for a moment I was confused as well.
So here is the explanation.
Short explanation
When you pass a reference type to a method and make a change to its property, the object outside the method CAN SEE the property change because the object itself remains the same.
When you pass a reference type to a method and make a change to the instance itself, the object outside the method CANNOT SEE the change because inside the method you basically started pointing to another object. So the object changed inside the method and remained there as a stranger.
Long explanation
Suppose you have a reference type instance where you get the value from database.
using (var context = new MyAdventureWorksEntities2())
{
Product p = context.Products.Where(item => item.ProductID == 1000).First();
Console.WriteLine(p.Name); // p.Name = "INITIAL NAME"
UpdateName(p);
Console.WriteLine(p.Name);
}
And here is your UpdateName method:
public static void UpdateName(Product p)
{
p.Name = "UPDATED NAME";
}
This code emits the following result:
INITIAL NAME
UPDATED NAME
HOWEVER, if you change the method to the following:
public static void UpdateName(Product p)
{
using (var context = new MyAdventureWorksEntities2())
{
p = context.Products.Where(item => item.ProductID == 1003).First();
// p.Name = "ANOTHER PRODUCT NAME"
}
}
your result will be:
INITIAL NAME
INITIAL NAME
Note that I didn't touch the ref keyword at all.
And perhaps after those examples the short description will be much more comprehensible.
I have a C# class that does some parsing of XML passed in to its one public method. The idea is that the method pulls info out of the XML, creates objects and sets up collections of them in public properties...
public class XmlParser {
public List<Customer> Customers { get; set; }
public void ProcessXml(string xml) {
XElement data = XElement.Parse(xml);
CreateEntities(Customers, data);
// do other stuff...
}
}
This way, we can do things like this in the calling code...
XmlParser xp = new XmlParser();
xp.ProcessXml(xml);
// do something with xp.Customers
I am trying to write a private generic method in the parser class, which would be used by the ProcessXml() method, and save me writing boilerplate code over and over again. The beginning of this method looks like this (other parameters missed out for clarity)...
private void CreateEntities<T>(List<T> collection, XElement data) {
if (collection == null) {
collection = new List<T>();
}
// process the XElement passed in, and add objects to the collection
}
I'm trying to use it like this...
CreateEntities(Customers, data);
...where the other parameters allow the compiler to know the generic type, and allow the method to know which entities to create etc.
However, the problem I have is that whilst the method itself works fine, and the collection variable is populated correctly, the public Customers property remains null.
I thought that passing a reference type, such as a List<> to a method allowed the method to modify the type, and have those changes seen outside the method, like in the answer from recursive in this SO post (I know that's a Dictionary, but I would have thought the principle would be the same).
Howcome my method can set collection to a new List<>, but Customers (which is the same object) remains null?
Update: Sigh, I ought to learn to read error messages!
Before I posted my question, I had tried passing the collection by ref, and it gave me compiler errors. I obviously didn't pay enough attention to the messages before moving on to plan B.
Having read the replies here, I tried ref again, and spotted that the compiler error was because I was trying to pass a public property by ref, which is not allowed. I changed the property from an automatic one to one with a backing field, passed the backing field by ref and it all works fine!
I thought that passing a reference type, such as a List<> to a method allowed the method to modify the type, and have those changes seen outside the method
You're getting confused with passing a parameter by reference (using the ref modifier), and passing a reference by value.
When you pass the value of a reference type (e.g. List<Customer>) to a method, you're still passing that argument by value by default. You can change the contents of the object that the variable's value refers to, but you can't change which object the original argument referred to, which is what you're trying to do.
Think about it like this... if I hand someone a piece of paper with my home address on, then they can do two things:
They can go to my house and paint my front door red
They can cross out my address and write a different address on the piece of paper
I will be able to see the result of the first action - it's changing something about the house itself. I won't be able to see the result of the second action, because it's just changing what's on the piece of paper... which is just a copy of what I know to be my home address.
For more details, refer to my article on parameter passing in C#.
To fix your problem, I would just change your CreateEntities method to return a list, rather than accepting one:
private List<T> CreateEntities<T>(XElement data)
{
var list = new List<T>();
// Populate the list...
return list;
}
If the caller wants to add those to an existing list, they can do so easily.
I think you missing the passing reference type by using ref. For more information ref (C# Reference)
Take a look at the following program:
class Test
{
List<int> myList = new List<int>();
public void TestMethod()
{
myList.Add(100);
myList.Add(50);
myList.Add(10);
ChangeList(myList);
foreach (int i in myList)
{
Console.WriteLine(i);
}
}
private void ChangeList(List<int> myList)
{
myList.Sort();
List<int> myList2 = new List<int>();
myList2.Add(3);
myList2.Add(4);
myList = myList2;
}
}
I assumed myList would have passed by ref, and the output would
3
4
The list is indeed "passed by ref", but only the sort function takes effect. The following statement myList = myList2; has no effect.
So the output is in fact:
10
50
100
Can you help me explain this behavior? If indeed myList is not passed-by-ref (as it appears from myList = myList2 not taking effect), how does myList.Sort() take effect?
I was assuming even that statement to not take effect and the output to be:
100
50
10
Initially, it can be represented graphically as follow:
Then, the sort is applied myList.Sort();
Finally, when you did: myList' = myList2, you lost the one of the reference but not the original and the collection stayed sorted.
If you use by reference (ref) then myList' and myList will become the same (only one reference).
Note: I use myList' to represent the parameter that you use in ChangeList (because you gave the same name as the original)
You are passing a reference to the list, but your aren't passing the list variable by reference - so when you call ChangeList the value of the variable (i.e. the reference - think "pointer") is copied - and changes to the value of the parameter inside ChangeList aren't seen by TestMethod.
try:
private void ChangeList(ref List<int> myList) {...}
...
ChangeList(ref myList);
This then passes a reference to the local-variable myRef (as declared in TestMethod); now, if you reassign the parameter inside ChangeList you are also reassigning the variable inside TestMethod.
Here is an easy way to understand it
Your List is an object created on heap. The variable myList is a
reference to that object.
In C# you never pass objects, you pass their references by value.
When you access the list object via the passed reference in
ChangeList (while sorting, for example) the original list is changed.
The assignment on the ChangeList method is made to the value of the reference, hence no changes are done to the original list (still on the heap but not referenced on the method variable anymore).
This link will help you in understanding pass by reference in C#.
Basically,when an object of reference type is passed by value to an method, only methods which are available on that object can modify the contents of object.
For example List.sort() method changes List contents but if you assign some other object to same variable, that assignment is local to that method. That is why myList remains unchanged.
If we pass object of reference type by using ref keyword then we can assign some other object to same variable and that changes entire object itself.
(Edit: this is the updated version of the documentation linked above.)
C# just does a shallow copy when it passes by value unless the object in question executes ICloneable (which apparently the List class does not).
What this means is that it copies the List itself, but the references to the objects inside the list remain the same; that is, the pointers continue to reference the same objects as the original List.
If you change the values of the things your new List references, you change the original List also (since it is referencing the same objects). However, you then change what myList references entirely, to a new List, and now only the original List is referencing those integers.
Read the Passing Reference-Type Parameters section from this MSDN article on "Passing Parameters" for more information.
"How do I Clone a Generic List in C#" from StackOverflow talks about how to make a deep copy of a List.
While I agree with what everyone has said above. I have a different take on this code.
Basically you're assigning the new list to the local variable myList not the global.
if you change the signature of ChangeList(List myList) to private void ChangeList() you'll see the output of 3, 4.
Here's my reasoning...
Even though list is passed by reference, think of it as passing a pointer variable by value
When you call ChangeList(myList) you're passing the pointer to (Global)myList. Now this is stored in the (local)myList variable. So now your (local)myList and (global)myList are pointing to the same list.
Now you do a sort => it works because (local)myList is referencing the original (global)myList
Next you create a new list and assign the pointer to that your (local)myList. But as soon as the function exits the (local)myList variable is destroyed.
HTH
class Test
{
List<int> myList = new List<int>();
public void TestMethod()
{
myList.Add(100);
myList.Add(50);
myList.Add(10);
ChangeList();
foreach (int i in myList)
{
Console.WriteLine(i);
}
}
private void ChangeList()
{
myList.Sort();
List<int> myList2 = new List<int>();
myList2.Add(3);
myList2.Add(4);
myList = myList2;
}
}
Use the ref keyword.
Look at the definitive reference here to understand passing parameters.
To be specific, look at this, to understand the behavior of the code.
EDIT: Sort works on the same reference (that is passed by value) and hence the values are ordered. However, assigning a new instance to the parameter won't work because parameter is passed by value, unless you put ref.
Putting ref lets you change the pointer to the reference to a new instance of List in your case. Without ref, you can work on the existing parameter, but can't make it point to something else.
There are two parts of memory allocated for an object of reference type. One in stack and one in heap. The part in stack (aka a pointer) contains reference to the part in heap - where the actual values are stored.
When ref keyword is not use, just a copy of part in stack is created and passed to the method - reference to same part in heap. Therefore if you change something in heap part, those change will stayed. If you change the copied pointer - by assign it to refer to other place in heap - it will not affect to origin pointer outside of the method.
I have the following code in C#:
IList<string> myList = null;
myList.Add(temp);
temp is a string that is decalred elsewhere and is not null (I checked it). I keep getting the following error at the line myList.Add(temp); "Object reference not initialised to an instance of an object"
What am I doing wrong here???
Updating the quesiton: I have already tried new
IList<string> myList = new List<string>();
as most of you suggested andget the following from Intellisense:
Cannot create an instance of the abstract class or interface Systems.Collections.Generic.Ilist.
Thanks for your previous answers. Now I am running into a peculiar problem. My datareader has an empty string in it. (1 field in the sql server table is blank. that is string.Empty). Is there a way to get rid of this inside the reader (I mean rdr here)??
you need to initialize the list first:
IList<string> myList = new List<string>();
...
Please note that on the right of = you have to write List<string> not IList<string> since IList<string> is an interface, whereas List<string> is a class that implements that interface.
The line:
IList<string> myList = null;
does not give you a list, but an empty reference to where a list could be.
IList<string> myList = new List<string>();
would properly instantiate myList, so you can use it (Add, Remove, etc.).
Here, take a look at this tutorial to better understand variable initialization.
From http://www.csharphelp.com/2007/03/objects-classes-in-c/
Person Michael = new Person();
In the first line of code we specified integer variablecalled age. In the second line we specified first the type of Object we need tocreate followed by the object’s name followed by a reserved operator called new and we end by typing the class name again followed byparenthesis “()”.
Let’s understand it step-by-step. Specifying the class nameat the beginning tell the C# Compiler to allocate a memory location for thattype (C# compiler knows all the variables and properties and methods of theclass so it will allocate the right amount of memory). Then we followed theclass name by out object variable name that we want it. The rest of the code”=new Person();” callthe object’s constructor. We will talk about constructor later but for nowunderstand that the constructor is a way to initialize your object’s variablewhile you are creating it not after you create it. For example, The Michaelobject we created it in the last section can be written as following :
Person Michael = new Person(20, “Brown”);
here I specified the variable’s values in the parameter listso I initialized the variables while I’m creating the object. But for this codeto work we will need to specify the constructor in the Person class and I willnot do that here because constructor section will come in later articles. Ithink you got a good introduction about Classes and Objects not I will completein in my next article and I will talk about constructors and building blockscoping. I hope you got a new thing from my article.
Updating the quesiton: I have already tried new Ilist() as most of you suggested andget the following from Intellisense: Cannot create an instance of the abstract class or interface Systems.Collections.Generic.Ilist
You cannot create instances of an Interface. IList<T> is an interface. Like the others have said here you initialize it with an instance of a concrete class that inherits the interface. Notice how they use new List<String>() not new IList<String>();
IList<String> items = new List<String>();
string[] splitstr =
this.strArraylist1[this.comboBox1.SelectedIndex].Split(delimeter, 5);
this.textBox4.Text = splitstr[1];
At this statement I'm getting the error:
Object reference not set to an
instance of an object
I'm guessing strArraylist1 is null, or one of it's items is null. If you try and perform a method on something that is null then you will get that error.
For example, this will throw an Object reference not set to an instance of an object error.
string[] strArrayList1 = new string[] { null, "Bar" };
string result = strArrayList[0].Split(delimeter, 5); // Error will occur here
The following would work fine:
string[] strArrayList1 = new string[] { "Foo", "Bar" };
string result = strArrayList1[0]; // Result will be "Foo"
Other possibilities are that comboBox1 or textBox4 are null. Although as they're probably controls on your form, that's unlikely, so my bet is that strArrayList1 is the culprit, so check the contents of strArrayList1. If you are calling Split on a null item, as per my example, that'll be the culprit.
You have got a System.NullReferenceException. One of you objects was null and can not be used:
strArraylist1
comboBox1
textBox4
Use the debugger, set a breakpoint, hover with the mouse over each object to see wich one. Once you found it make sure that is instanciated at the time you use it.
It means the result of this.strArraylist1[this.comboBox1.SelectedIndex] is null, so when you try to call .Split(delimeter, 5) the object it is being called by is null, hence the exception.
"Object reference not set to an instance of an object" means that you're trying to use the value that is associated with a variable, as an object reference, but that value is null, rather than point to an object. Which means that any operations you do on that supposed object will not work, because you're effectively doing: null.Something()
Consider this:
string[] splitstr = null;
this.textBox4.Text = splitstr[1];
This doesn't work, because the variable splitstr doesn't hold an object, it holds null.
Then, when you go on to do splitstr[1], you effectively trying to do null[1] - which can't work, since null isn't an array, let alone one with at least two elements in it.
In your example, you could have nulls stored in:
strArraylist1
this.comboBox1
strArraylist1[this.comboBox1.SelectedIndex]
this.textBox4
An additional potential problem with your code is that you may go out of bounds on the arrays splitstr and strArraylist1.
Check that:
splitstr will always hold at least two elements (because of [1])
and that strArraylist1 will always hold enough to accomodate the number produced by this.comboBox1.SelectedIndex.
Add a break point to the first line in your give code and look for a null value or an index out of range. That should give you the clue to catch the error.
I had this problem in WPF, my problem was caused by the root, instead of using the project root, it was using the root of the class, all objects where visible in the class but it did not get passed the class root when i called it, the way around it is to include the object trough the function in the class.
//Class
public void call(object b)
{
//Do stuff
}
//main Thread
Core Menu = new Core();
Menu.call(Object);