For a method's local variables, value types are indeed stored on the stack and reference types on the heap. Reference types are a little confusing, however, because they are really stored in two parts: the reference, which is stored on the stack just like a value type, and the 'body', which is stored on the heap. Now, lets look at the body of a type (reference type or value type). Reference types and value types can have fields of both types. The fields of a type are (effectively) concatenated together. So the body of a type is the concatenation of the contained value types and the references to the contained reference types. And this body is 'a chunk of memory' which is stored somewhere - on the stack (if its the body of a value type), on the heap (if its the body of a reference type) .. or nestled inside the body of some other type (if its a field in another type). So, it may be more useful to think of value types as being stored 'where they are declared' instead of thinking of them as being stored on the stack, while reference types have their reference stored where the variable is declared, and its body is always stored on the heap.

FYI - while the use of is and as are what's appropriate for your problem, as lukasz_nowakowski and OriginalGriff have said, your example code used GetType ... which put me in mind of how to do a similar test on Types, rather than objects:

Type typeOfC = typeof(C);
Type typeofSomeObject = someObject.GetType();

// ...
if (typeOfC.IsAssignableFrom(typeofSomeObject))
	{
	// ...
	}
// ...

Similar to John Simmons's answer, but let each form's constructor take a ClassA. Now, create the ClassA before creating either form, and pass it to the form before showing it. The important fact is that neither form 'owns' (or instantiates) the shared instance of ClassA, rather, some larger scope owns it and makes it available to both forms that want to use it. An alternative to passing the ClassA into the constructor is to make a ClassA property on each form, and assign the property before showing the form. This is a very common pattern when presenting dialogs whose purpose is to modify data that is used elsewhere. Here's a snippet:

public void DoFormStuff(ClassA ca)
	{
	using (MyForm frm = new MyForm())
		{
		frm.ClassA = ca;
		frm.ShowDialog(this);
		}
	}

For text data, look for lines that don't contain an embedded space, then append " 0":

public List<string> CleanupText(List<string> inputLines)
	{
	List<string> outputLines = new List<string>();
	foreach (string s in inputLines)
		{
		// Note: the Trim() and Replace() ensure that (a) there are no false hits and (b) no false misses, respectively
		if (s.Trim().Replace('\\t', ' ').Contains(" "))
			outputLines.Add(s);
		else
			outputLines.Add(string.Concat(s, " 0"));
		}
	return outputLines;
	}

If you want to modify the collection in place, you'll have to replace the foreach() with a for() and an index into the list - since foreach() loops disallow modifying the collection they are iterating. To do this with Excel you'll have to iterate rows (the end condition being a cell in the first column that is empty), looking for cells in the 2nd column that are blank and inserting a '0' into those blank cells. I've not done enough MSOffice interop to be able to give you a code example.

Yeah. My fingers got ahead of my brain and I posted my message before I saw that you had already said the same thing. :doh:

Dig a little deeper with Reflector and you'll see that neither TextBox nor TextBoxBase maintain any .Net string at all - they are simply wrappers around the Win32 text box. Anyone know, or care to guess, how Win32 handles a window's text value?

You do need a separate class to do what you want to do, and it needs to expose an event that the class that uses it must handle in order to respond to changes in ball states. Here's an example (compiles under VS2008):

namespace BallStateExample
{
enum State {Flashing, Played, NotPlayed}
delegate void BallStateChanged(BallStateChangedEventArgs e);

class BallStateChangedEventArgs
	{
	public int BallIndex { get; set; }
	public State NewState { get; set; }
	}

	
class Balls
	{
	private readonly State\[\] \_balls;
	
	public Balls(int numBalls)
		{
		\_balls = new State\[numBalls\];
		}
		
	public event BallStateChanged BallStateChanged;

	private void OnBallStateChanged(int index, State newState)
		{
		if (BallStateChanged != null)
			BallStateChanged(new BallStateChangedEventArgs { BallIndex = index, NewState = newState });
		}
		
	public State this\[int index\]
		{
		get { return \_balls\[index\]; }
		set
			{
			\_balls\[index\] = value;
			OnBallStateChanged(index, value);
			}
		}
	}
	
	
class BallUser
	{
	private const int NUM\_BALLS = 42;
	
	public BallUser()
		{
		Balls = new Balls(NUM\_BALLS);
		Balls.BallStateChanged += Balls\_StateChanged;
		}
		
	private void Balls\_StateChanged(BallStateChangedEventArgs e)
		{
		// Take action in response to a ball state change
		}

	// ...

	// Auto-property (so no backing store need be declared)
	// Private set accessor to prevent consumers of BallUser from
	// assigning to the property (an action reserved for the constructor of BallUser).
	public Balls Balls { get; private set; }

	// ...
	}
}

I'd welcome the office assistant characters - if there was a way I could watch them die a gruesome animated death when I switch them off (Oh - and give me choices about how to kill them, too). Sorry, but when I'm at work (or at play on my PC) I don't need cutesy animations pulling my attention away from the task at hand. In fact, I'm just not into cutesy, whenever or wherever. Sorry to those of you who love it, but I don't. X|

We all have dual 19" (maybe 21" - bigger than I've ever had before) at work - and it's the best money the company ever spent on developers. I thoroughly recommend using one or more 19" to 21" panels (resolution of ~1400 x ~1200). The extra screen real-estate means that your solution explorer can be wide enough for comfort - and you still have room in the editor window for long lines of code (necessitated because of VeryLongFunctionNamesThatTellTheirWholeLifeStory():laugh:.) A lot of my work requires that I have a remote session connected to a second PC: having dual monitors (one dual head video card) is perfect - I can have each PC in its own monitor, as if the 2nd was local, not remote across the network. And when I'm not connected to a remote PC the 2nd monitor is great for displaying the app I'm debugging, while VS is full screen on the other monitor. Chris

Thath why we use keyboardth, thilly.;P

IMO MS won't eliminate C++ (and probably not COM, either) for applications because, as one other poster indicated - there are just some tasks better done in C++. Sometimes that's for performance reasons (in which case they could support C++ but not the C++ Windows API); other times, however, there are things that can be done through the API that simply cannot be done throught the .Net object set. Yet. And, in general they have shown a great desire to remain backwards compatible - which suggests that they would not happily release an OS that caused people with legacy apps to say "Well, the app is more important than the OS upgrade: sorry MS, you don't get my upgrade revenue this time." That, probably, is the "killer app" of programming support - will it help or hinder the sale of the next OS? Balanced against, of course, a projection of total revenue earned on that OS vs. total development and support costs involved in persisting the old API. ~Chris Ice is like water, only harder.

Consider that MVC is an abstraction and is identically appropriate in both the web and the desktop ('event driven' world). In other words, events, or no events, is not an issue. Consider, also, that the web world is a variant of the event driven model of the typical windows application - and true non-event-driven models are (largely) a thing of the past (being any application without a universal 'dispatch' mechanism). IMO the 'gap' between the browser and web server should be considered an aspect of some pattern other than MVC. This is difficult (and I'm only formulating my thoughts as I type) because the controller of MVC is 'all about' managing the interaction, and the question "if it's not the one managing how the browser and the server-side code interact, what is it there for?" arises. For me, the controller in MVC is about the abstract flow of control: If I click this button the controller knows which model I'm currently working with and how to inform the model that a specific action has been requested. The view, as we know, then needs to get from the model the revised data it needs to display. MVC on the web works best, for me, if ALL of this behavior is server side; that means that the view part of MVC is on the server: I am distinctly NOT making any kind of correlation between the browser and the MVC View. In fact, the gap between the browser and server is an internal detail of the view (and also an internal detail of the controller). In other words, inside the View and the Controller there is, effectively, an implementation of the Proxy pattern. HTH Chris Use what talents you possess; The woods would be very silent if no birds sang there except those that sang best. (William Blake)

I've moved through Assembler, C, C++ and now to C#; I've played in MFC along the way (and dabbled in Mac & Unix too :). Of the Win32 stuff - I know about messages, messages, messages. And some about handles. And that's it. I'd say that knowing the whole Win32 API is probably wasted effort; knowing parts of it, however, would be valuable. There are two topics I'd suggest getting clear about: 1. Learn about messages and the message pump - how messages get generated & how windows process them. Learn about the different types of messages that get passed to / from windows - when they happen & why. Learn about the order in which messages get generated, and the order in which parent/child relationships of windows get the opportunity to handle them. 2. Learn about resources and handles. Handles are the key to referring to windows, fonts, etc. - things that Windows manages for you. Learning about handles and about how they get created / destroyed will give you background knowledge that will support your understanding of MFC. Is (learning - from a book?) any of that _essential_ for working with MFC? Probably not. You'll have other programmers around you who can answer questions - or tell you exactly what to research. You could call this the 'learn it when you need it' approach; it also has the benefit of not using time on learning things you don't need. HTH Chris