Add() method in .NET (passing parameter)

Collection objects have Add() method in .NET. It is very important to understand how it works.

Code Block 1:
TableRow row = new TableRow();
for (int i = 0; i < resultFields.Count; i++)
{

foreach(string str in resultFields[i])
{
TableCell cell = new TableCell();
cell.Text = str;
this.Response.Write(str);
row.Cells.Add(cell);
}
tbl_rsltFields.Rows.Add(row);
}
In this example, if resultFields.Count is 2, how many rows do you think are in the tbl_rsltFields?
The answer is 1. It is worth noticing this case.

Code Block 2:
for (int i = 0; i < resultFields.Count; i++)
{
TableRow row = new TableRow();

foreach(string str in resultFields[i])
{
TableCell cell = new TableCell();
cell.Text = str;
this.Response.Write(str);
row.Cells.Add(cell);
}
tbl_rsltFields.Rows.Add(row);
}
In this case, the answer is 2.

Actually, if we try to add "row.Cells.Clear();" right after "tbl_rsltFields.Rows.Add(row)" in code block 1, there will be nothing contained in tbl_rsltFields at last. Based on this fact, we know that by calling Add() method, it only gets a copy of the reference, instead of making a copy of the whole row. So it acts like it is passing reference by value.

Application["UserCount"] += 1 doesn't work

Why does Application["UserCount"] += 1; incur compiler error? It's the same reason why Application["UserCount"] = Application["UserCount"] + 1; doesn't work either.

And once you know the correct way should be: Application["UserCount"] = (int)Application["UserCount"] + 1; you'll also know (int)Application["UserCount"] += 1; is wrong too.

What's wrong with Monitor::Enter()

Suppose we have the following variable we'd like to set as a state and we'd like to make it thread safe (at most one thread is allowed to access the variable):

bool workQueued;

Now if we write something like this, it's not gonna work:

Monitor::Enter(__box(workQueued));
try
{
workQueued = true;
}
__finally
{
Monitor::Exit(__box(workQueued));
}

Why it will not work? The problem is, after workQueued is boxed, the value is not store anywhere. So the second thread reaches here will execute Enter statement with another object value.

To make it work as desired, we need to create a object whose only purpose is to act like a lock:

Object* lock;

Then, we feed this object to Enter and Exit method:

Monitor::Enter(lock);
try
{
workQueued = true;
}
__finally
{
Monitor::Exit(lock);
}

LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification

What the heck?! If you've spent more than ten minutes just trying to find where to set EDITANDCONTINUE property in VC++ project property page, you are not alone. It can be set through: (Under Project Property Pages) Configuration Properties -> C/C++ -> General -> Debug Information Format.

OK. Now I've set it NOT to be /ZI and disabled incremental link, why the darn VS still complain the same warning. Remember that no matter how bizarre a problem seems to be, computer always works as expected. Why don't you check the project properties of other projects that this project depends on?

Visual Studio got stuck when opening sln file

Sometimes VS may get stuck when we double-click a .sln file. We can see the file name on which it got stuck. But even if we try to rename that file or replace with another one with the same name, it may still not work. In this case, try to delete the corresponding .suo file.

Problem caused by dll loading mistake

It is very common that we have two versions of dll: somedll.dll(for Release build) and somedll_d.dll(for Debug build). Because of the dll dependancy complications, if these two versions were load at the same time, it may not cause build errors. However, something wrong can happen during the run time.

For example, if there is a global variable in the source file whose output is somedll.dll/somedll_d.dll, that global variable may be initialized twice (once during the load time of somedll.dll and once during the load time of somedll_d.dll). The client code then will get confused on which of the two references to use. But the fact is, it should be only one instance of that global variable existing.

Time-saving Tips

1. Sometimes we may have weird link errors. Some of the errors will be gone if we try to delete the debug/release folder (clean) and rebuild the project.

2. If an environment involves several executables and dlls working together, their build version should match exactly. Otherwise, some bizarre behaviors may happen.