OK, assuming the class that needs to talk back is a member variable in your form class, you need a delegate so that the child class can push information back to the form. Once again, let me stress that the worker class shouldn't talk directly to the controls. Let the form do that, so that when you change the form in the future (you will, even if you don't believe me now) you won't have to worry about changing the worker to match. So, if your structure is roughly like this: public class MyForm : //yada yada { Private MyWorkerClass m_cMyWorker = new MyWorkerClass; Private RichTextControl rtMyTextControl; } then you really need delegate callbacks from MyWorkerClass that MyForm hooks in to. This keeps them separate and uncoupled. You may have to alter your intended approach a hair, but I promise you'll thank me later if you do. Rather than explain delegates, let me point you to an incredible article Chris Sells wrote on the topic. It also talks about the evils of tight coupling (not to beat the drum too much): http://www.codeproject.com/csharp/delegate\_bedtime.asp

I believe the difficulty you're having is that you're thinking of the problem from the wrong angle. It's not a mechanical thing. It sounds like you want two peer classes to communicate, OR you want an owned class to be able to call back to its owner. The problem is that you're coming at it from the wrong angle. Instead of the worker class pulling information from the form, your form should push information to the worker class. Why? Because the worker class is many more times likely to be re-used than is the form class. Forms are usually the most specific part of your app, and worker classes the most general. If it is an owned class getting information from its owner, don't do it. Instead have the owner push the information down to the owned class. This reduces your coupling of the two classes which will allow you to re-use this class some day. Remember, the first rule of generalized classes is the "I'll never" rule. Right now you're saying "I'll never need to re-use this class" which guarantees that you will. If that class accesses specific controls and/or properties in your forms class, you won't be able to re-use it. If this doesn't describe your problem, let me know more specifics and I'll show you another angle.

Is there any way to get a deployment project in Visual Studio.NET to give you a summary of what files it is including and, much more importantly, where it retrieved the files? I'll take anything, including VS Macros, command line, etc. John Woodard

I am developing a desktop app using .NET, and it is wonderful. Yes, you need the .NET runtime, but you can include it on your installation CD if you have one. The great thing about .NET is how easy and seamless it has made developing components and user controls. It's now a true peice of cake, basically it is COM the way it was always meant to be (even Don Box thinks so according to an associate of mine who knows him). Here where I work, the goal is all new development in .NET. And we don't take those decisions lightly.

Being a C++ programmer I understand where you're coming from. I'm a C++ programmer as well. However, this is not C++, and it's not a leak. I can't easily post the code. First of all, this is managed code. This is further proven by the fact that if I switch to a smaller list after the problem has happened, I can continue to run. Second, it's not like it's happening due to repeated operations. I can run all day, so long as I don't have too many controls up at one time. The first time I graph 100 at a time I fail, but I can choose 20 different lists of 10 in sequence and I still work fine so long as I don't do it too fast (so the GC has time to catch up). What it appears to be is that I'm limited to 16384 window handles. if each control has a window handle, that means 2 per bar (one for the bar, which is a UserControl, and one for the ToolTip window I assume), 108 bars per graph, Around 12 extra for scales and such on the graph, that's 24,000 window handles. This is almost certainly the problem. I changed it so that instead of a full-out control, each bar is defined by a helper class that renders it and the problem went away (obviously the helper class doesn't use a window handle, it just has the paint code). My question is, can I get around the 16K limitation (if that is indeed the limit)?

I'm having a problem where I run out of window handles, even though the number seems to be within the realm of the sane. What I'm doing is creating a scrollable list of bar charts. The bar charts are interactive, so what I did was make each bar a separate control. This made selecting, floating tooltips, and many other things very easy. They're built dynamically. I was very proud of this idea. Now, I have 100 bar charts, with 108 bars (in this case) each and say 12 other controls per chart (may be slightly less than that). That only amounts to 12,000 window handles, which even on 95/98 should be OK and I'm running XP Pro. I can't imagine that my main app window is using over 4,384 window handles. When I hit my AddRange, I run out of window handles and get "Error Creating Window Handle". I can't even do this with 50 charts. Any ideas on how to work around this without having to re-write my bar graph displays? Also, any idea on how spy on my application's window handle usage so I can determine exactly what I'm up against? John Woodard

I'm trying to make a combo box where the mouse wheel does not work and/or bubbles the event up to the parent. Creating a new ComboBox class where OnMouseWheel is overridden does not work, nor does adding an event handler for the MouseWheel event. In both cases I get the event, but the combo box has already scrolled, defeating the purpose. Even when I put in a breakpoint I can see the new item in the combo box before my breakpoint is hit. Basically, in this app changing a combo box means reading in a whole set of new data, so I want to force the MouseWheel to be only for the scrollable area of the display. John Woodard