A better way to write / read dozens of textboxes?

[RogerD]

Finally got a couple of hours to myself to look at this.

What do you mean by "C2337 isn't a listed error"? These Cxxxx error and Wxxxx warning numbers are great to simply copy-paste them into the search field at the top left of any MSDN page and hitting Return. The documentation on the error usually is the first search hit, or at least among the top three.

That's what happens relying on local help my internet access is limited to one dongle and my wife...

I have experimented with that too, but with zero actual success. IContainer and the related interfaces definitely seem to have something to do with that, but I'm still uncertain about their concrete roles. I find the IContainer MSDN sample rather unintuitive and uninstructive: If I'd be writing book list code, I would create my book class as needed and place instances of it in one of the generic collections or a database, instead of making use of these interfaces that apparently are originally meant for something completely different. I'd really appreciate a more practical example. And if you'd find out anything interesting in that direction, of course I'd appreciate that too. Perhaps the actual answer is rather simple and I was just too dumb to see it right in front of my eyes.

I have had a brief look at Component class again with a little success. Create a class and drag components onto the "designer" - I put a single button on - and modified the .h slightly including inheriting from "Panel":

namespace TrafficLightDemo {

	/// <summary>
	/// Summary for Fred
	/// </summary>
	public ref class Fred : public System::Windows::Forms::Panel //System::ComponentModel::Component
	{
	public:
		Fred(void)
		{
			InitializeComponent();
			//
			//TODO: Add the constructor code here
			//
			this->Controls->Add(button1);
		}

You still have to hand enter properties like Location but it's definitely easier than entering the whole thing (or perhaps lifting from a prototype.) It also allows events to be coded "automatically" so it does reduce the typing quite a bit. In this simple test the IContainer constructor doesn't appear to do anything - is that related to changing the inheritance from Component to Panel?

I have, however, also experimented with some technique to "hijack" an existing Designer-created control at runtime and replace it with my hand-coded one. That way one can reserve space on the form for the custom control at design time by creating a placeholder control. But that only ever is about intuitive if the placeholder control is rather similar to the custom one, ideally of its base class. I haven't touched the code for that since more than a year, but it's still experimental and rather hackish. That's because I never really took the effort to develop this to real practical usability, since I've been perfectly happy with the techniques described above. We could discuss that technique, but I'd probably need to tidy up the code to be presentable, and that would definitely deserve a new thread.

Would it be an idea to create a module on a dummy form complete with events and just lift the designer code into the class constructor? Would it not be easier to use a panel of the same dimensions as a placeholder or am I (grossly) over-simplifying?