A better way to write / read dozens of textboxes?

Hi there, how are you? :wave:

I'm using VC++ 2008 / Windows Forms Application (CLI)

My question is quite simple:

Let's suppose I have 60 textboxes that I would like to send a message. So, my first obvious and extensive option would be:

textBox1->Text = "My message";
textBox2->Text = "My message";
textBox3->Text = "My message";
....
....
textBox60->Text = "My message";

That's obviously not a professional manner to code a program!

How could I do the same by using some sort of loop? I know how to do such thing sending data to an array for example, but to print and read textboxes, numerics updowns, trackbars, etc, I have no idea. :o

I'd really appreciate your input on this matter.

Thank you in advance!

All best,

Fernando

Quote:

---

Originally Posted by fernando306

How could I do the same by using some sort of loop? I know how to do such thing sending data to an array for example, but to print and read textboxes, numerics updowns, trackbars, etc, I have no idea. :o

---

It's the same way, you store the textboxes in an array or some other container. Then set the text in a loop.
However, in terms of user interface design, it would probably be better to use a list raster than 60 edit boxes.

Hi D_Drmmr, thanks for your input!

Ok, but how can I do that?

For example, if the names of my textboxes are textBox1 ... textBox60, that's a name that I can't use a variable in the middle to increment. I can't do something like textBox[n]. That's why I'm lost! Could you provide me a piece of code for that? I'm sorry to ask such a primary thing, but I'm used to code C for microcontrollers, where you don't have any of that. :)

About the LIST, ok it might be a replacement for textboxes, but how about the NumericUpDowns, TrackBars and ComboBoxes? I have the same problem. For you to have a better idea, these are Parametric audio EQ bands:

Attachment 30523

Quote:

---

Originally Posted by fernando306

Hi D_Drmmr, thanks for your input!

Ok, but how can I do that?

For example, if the names of my textboxes are textBox1 ... textBox60, that's a name that I can't use a variable in the middle to increment. I can't do something like textBox[n].

---

Sure you can. When you add a text box to a form, VS will add some code like this.

Code:

---

                void InitializeComponent(void)
                {
                        this->textBox1 = (gcnew System::Windows::Forms::TextBox());
                        this->SuspendLayout();
                        //
                        // textBox1
                        //
                        this->textBox1->Location = System::Drawing::Point(12, 12);
                        this->textBox1->Name = L"textBox1";
                        this->textBox1->Size = System::Drawing::Size(100, 20);
                        this->textBox1->TabIndex = 0;

---

Instead of creating a single text box, you can also create an array of text boxes. Then call the same code to initialize each of them. It's probably best to put this code outside the InitializeComponent function, else the form editor may get lost. Not sure about that, though.

Quote:

---

Originally Posted by fernando306

About the LIST, ok it might be a replacement for textboxes, but how about the NumericUpDowns, TrackBars and ComboBoxes? I have the same problem. For you to have a better idea, these are Parametric audio EQ bands:

---

If your controls have specific meaning, I would suggest using more useful names than textBox1, etc. If you have the same set of controls for each band, then you should wrap those controls in a class, such that you can simply create several instances of the class, rather than duplicate the code.

Quote:

---

Originally Posted by fernando306

Hi D_Drmmr, thanks for your input!

Ok, but how can I do that?

For example, if the names of my textboxes are textBox1 ... textBox60, that's a name that I can't use a variable in the middle to increment. I can't do something like textBox[n]. That's why I'm lost![...]

---

Yeah, in fact that can be done. :) However...

Quote:

---

Originally Posted by D_Drmmr

[...] It's probably best to put this code outside the InitializeComponent function, else the form editor may get lost. Not sure about that, though.

---

Caution! Never ever do that! The code between #pragma region Windows Form Designer generated code and #pragma endregion, which mostly comprises the InitializeComponent() function, is maintained by the IDE and must not be modified by the developer, under any circumstances, (There also is a comment clearly stating this at the beginning of the region, but quoting it here would not be of much use, since it's German in my version, and certainly most users around here neither are using that version nor speak German.) The IDE keeps some sort of checksum of the region and gets really angry should anyone else modify it.

But D_Drmmr's InizializeComponent() snippet contains a really important hint: The IDE sets the Name property of each control it creates equal to the name of the control variable. (The property can be different from the variable name, but only if you change it in your code, create the control yourself or assign an IDE-generated control object to another variable in your code.) Furthermore, the controls are accessible by that name in the form's controls collection. And that's why you can do this:

Code:

---

for (int i = 1; i <= 60; ++i)
  Controls[String::Format("textBox{0}", i)]->Text = "Your message";

---

But I'm afraid that's somewhat inefficient. Probably better would be iterating over the controls rather than doing a lookup for every single one:

Code:

---

for each (Control ^ctl in Controls)
  if (ctl->Name->StartsWith("textBox"))
    ctl->Text = "Your message";

---

Distinguishing the text boxes from other controls by their type rather than their name probably would be even more efficient, but making use of the Name property allows you to apply some naming scheme to narrow down the iteration to a certain subset of the text boxes, like, e.g., txtBoostCut1 to txtBoostCut60. That's probably helpful: I have seen text boxes of different use on your screen shot.

I have also seen that your text boxes (and other controls) are inside group boxes. Controls inside group boxes are children of the group box, not the hosting form. That would make the scheme outlined above a bit more complex in that you'd need to iterate over the group boxes and then over the controls inside, somewhat like this:

Code:

---

for each (Control ^ctl in Controls) {
  GroupBox ^gbx = dynamic_cast<GroupBox ^>(ctl);
  if (gbx) {
    for each (Control ^ctlInner in gbx->Controls)
      if (ctlInner->Name->StartsWith("textBox"))
        ctlInner->Text = "Your message";
  }
}

---

This also demonstrates distinguishing controls by type, as mentioned above, with regard to the group boxes.

Finally, the most elegant and efficient approach would probably be, like already suggested by D_Drmmr, to create your own class to bundle the controls for each channel. I'd probably do that myself in the form of an EQ band control class, derived from Panel or even GroupBox. That would be some additional effort up-front but is likely to pay later by simplifying things.

(Snippets not tested, may contain bugs.)

Also, if you have a bunch of controls already placed in the designer, and you opt not to create a specialized class to structure things in a better way, you should know that, assuming the number of UI elements is not going to change at runtime, you can search for the text boxes once, say, after the InitializeComponent() method, store the results, and reuse them throughout the rest of the app. That is, you don't want to search for then every time - find them once, and that's it.

Hi Cthulhu, long time no see! :wave:

Really a good idea. ... actually, one that I already had myself while writing post #5, but considered it "probaly premature optimization at the moment", so I postponed it to the "advanced" section and potential later posts, mainly to keep post #5 compact. (No kidding! :))

When it's about a moderate number of IDE-generated controls that is unlikely to change frequently, I actually even tend to hard-code these control arrays, like this:

Code:

---

array<TextBox ^> ^atxtSpecificPurposeBoxes = gcnew array<TextBox ^>{
    txtSpecificPurpose1, txtSpecificPurpose2, txtSpecificPurpose3
  };

---

In one real-life application I actually had 46 IDE-created picture boxes (on a single form, of course), and there were eight control arrays (with intersections) referring to them, everything hard-coded. Man I tell you, that was tideous... :rolleyes: In the current version of the app, however, these boxes, now of a PictureBox-derived type, are programmatically created by a static member function of that derivate class, along the lines of this:

Code:

---

  m_aclSec = ClockLight::CreateLightArray(9, ptNextLocation, szLightLocationIncrement, 7, nullptr);
  lstclAll->AddRange(m_aclSec);
  aclTemp = ClockLight::CreateLightArray(1, ptNextLocation, szLightLocationIncrement, -1, nullptr);
  lstclSeparators->AddRange(aclTemp);
  lstclAll->AddRange(aclTemp);
  m_acl10Sec = ClockLight::CreateLightArray(5, ptNextLocation, szLightLocationIncrement, 6, nullptr);
  lstclAll->AddRange(m_acl10Sec);

---

There's still the tideosity (is this really an english word?) of assigning the control objects to the "what purpose is that for?" arrays, but the overall cut-down on manual effort was about factor seven. (The total count of these objects has increased to 62 in the meantime, BTW.)

Eventually, the OP's scenario will likely result in programmatic creation of an array of EQ band (control) objects. ... at least I hope so... :) One secondary advantage that would have would be simplifying to make the total number of bands widely configurable.

Hey Eri523, that was incredibly helpful! Thank you so much. I'm having problems with my HP laptop (hate it) , but I will certainly test your solution ASAP and post back here!!!

Quote:

---

Originally Posted by Eri523

Yeah, in fact that can be done. :) However...

Code:

---

for each (Control ^ctl in Controls) {
  GroupBox ^gbx = dynamic_cast<GroupBox ^>(ctl);
  if (gbx) {
    for each (Control ^ctlInner in gbx->Controls)
      if (ctlInner->Name->StartsWith("textBox"))
        ctlInner->Text = "Your message";
  }
}

---

---

I see... And I have these GrouBoxes inside a TabPage, so probably I have to first look for GroupBoxes inside the TabPage, then for NumericUpDowns inside the Groupboxes, right?

How can I perform a search in TabPage2 for example?

Wish me luck burning the midnight oil, and if you have any tips it will be very welcome! :thumb: I'm honestly still feeling kinda lost! :rolleyes:

Hi there again!

Finally got my computer back and now testing some code, I successfully located the desired control (which is a NumericUpDown) inside the tabPage and the GroupBox! :) Thanks Eri523!!! I made a small test using the visible property as you can see...

However... I can't access all the properties, see the screenshot bellow. For example, "text" is available, while "value" is not. Any ideas?!

Attachment 30529

And I tried to access the control in a different manner, referring to it as the element of the array instead of it's name, still I can't access the "value" property, but I can access other properties such as "visible" for example. Controls[8] is the NumericUpDown that I'm trying to change the value ;)

Attachment 30531

I just don't understand why when accessing the control by its full name (directly) I get access to all of its properties, but when I access the same control by it's array position "Controls[8]" or from "ctlInner" I get access for SOME of its properties but not all of them... :confused:

Quote:

---

Originally Posted by Eri523

Hi Cthulhu, long time no see! :wave:

---

Hi Eri :wave:

Quote:

---

Originally Posted by fernando306

And I tried to access the control in a different manner, referring to it as the element of the array instead of it's name, still I can't access the "value" property, but I can access other properties such as "visible" for example.

[...]

I just don't understand why when accessing the control by its full name (directly) I get access to all of its properties, but when I access the same control by it's array position "Controls[8]" or from "ctlInner" I get access for SOME of its properties but not all of them... :confused:

---

It's because when you use "Controls[i]" or "ctlInner" the type of the control is Control, which is at the root of the inheritance hierarchy for WinForms controls and even forms themselves. Basically, the variables you use are of a more abstract type - you just need to cast them back to their actual type. When you access the control "by its full name", the type of the variable is NumericUpDown, so you can access NumericUpDown-specific members. As you move up the inheritance chain, the representations become more and more abstract. A variable of type Control cannot access NumericUpDown-specific members since the variable might refer to anything that is a control, not only a NumericUpDown - it could be a TextBox, a Panel, a Label, a Form...
However, you know what the actual type is, so you can do the cast.

Now, in C# (which is the angle I'm coming from), you'd simply do:

NumericUpDown nupdwn = (NumericUpDown)ctlInner;

But, C-style casts are considered a no-no in C++ (without a particularly good reason if you ask me...), so use whatever casting operator is appropriate in the context of C++/CLI.

Quote:

---

Originally Posted by fernando306

I just don't understand why when accessing the control by its full name (directly) I get access to all of its properties, but when I access the same control by it's array position "Controls[8]" or from "ctlInner" I get access for SOME of its properties but not all of them... :confused:

---

The reason for this is the fact that the items inside the controls collection are of type Control ^. All the Windows Forms control classes (including Form) are derived from that class, so they all are Control objects, just with some extras (the magic of polymorphism... :)). And as what you get out of the controls collection is of type Control ^, initially you can just access the basic members of that class. So now the object you retrieved from the controls collection actually is of type NumericUpDown ^, just disguised as a Control ^. You do know that, but the compiler does not, so you need to tell it somehow, and that's done by casting.

The idea of that is already visible in the last snippet in post #5, though admittedly not very obvious. The dynamic_cast returns an object of type GroupBox ^ if it succeeds, otherwise nullptr (i.e. the object passed in istn't actually a GroupBox). So I then could access GroupBox-specific members via gbx, I'm just not making use of that ability, merely using the cast to check the object's concrete type.

There are three sorts of cast to choose from in such a scenario:

• dynamic_cast, as already mentioned: Will return nullptr in case of failure. Specifically useful when you're not actually sure about the concrete type of the object you have.
• safe_cast: Quite similar to the dynamic_cast but throws an InvalidCastException in case of failure. Most useful when you expect an object of a certain type but want to assert it. The difference may seem minor but is of great diagnostic value: safe_cast immediately throws an exception that clearly communicates what went wrong, while using a dynamic_cast the same way will result in a more general NullReferenceException being thrown when you try to use the returned handle, and that may be hundreds of code lines away from where the actuall error occurred. (The safe_cast has some more handy differences from the dynamic_cast but they're irrelevant in the context here, so I omit them for brevity.)
• static_cast: Simply assumes that the object you're casting actually is of the type you're casting to. It will result in the all-time popular undefined behavior in case of failure. I have read somewhere that a failed static_cast may even destabilize the entire .NET runtime and the hosting OS (i.e. Windows), but I, personally, have only seen it crashing my own app with rather cryptic symptoms; bad enough, though. It's way faster than the other two, but that's only ever relevant in really performance-critical code, and that's why I practically never use it in GUI code nor recommend doing that.

This snippet, adapted from you screen shot in post #10, illustrates that:

Code:

---

safe_cast<NumericUpDown ^>(gbx->Controls["Freq_OUT1_EQ" + x.ToString()])->Value = 1000;

---

It also accuounts for that, though it's according to my own recommendations, what you're doing in the screenshot snippet is inefficient: If you only want do access a single control of which you know the complete name, a direct lookup in the controls collection is the way to go.

TheGreatCthulhu, basically the same idea behind our two posts (no surprise, though, as they're answering the same question), but yours (of which the notification arrived here while I was writing mine) is much more compact (as usual... :)) and from a slightly different POV. Can only be helpful! :)

Quote:

---

Originally Posted by TheGreatCthulhu

But, C-style casts are considered a no-no in C++ (without a particularly good reason if you ask me...) [...].

---

I personally do use them, but rather rarely, and then mostly in the context of calls to native API functions. And the reason why I try to avoid them is not a "codiquette" one; it's because (at least to me) it's somewhat obscure what they actually do in C++[/CLI]: Depending on context, they sometimes behave like a static_cast and sometimes like a reinterpret_cast, and probably there are some more variants that don't come to mind now.

Congrats to 1k posts, BTW! :thumb:

Hi Eri523 and TheGreatCthulhu! :wave:

Thank you so much for your kind consideration helping me! Indeed it was the cast problem, I tested it and it works like a charm now! I am very pleased with your helpful posts and I appreciate that a lot. I'm new to C++ and Windows programming, I've been programing in C for embedded microcontrollers, so I'm still "getting used to it" :D Thanks to you I'm almost finished developing my Windows App and I understand things clearer now!

Kind Regards,

Fernando P.

I'm on my first VC project so followed this thread with avid interest.:thumb:

What I would appreciate is one or more pointers to info on how to achieve what has been hinted at here, namely encapsulating controls in a class.

Quote:

---

Originally Posted by Eri523

Finally, the most elegant and efficient approach would probably be, like already suggested by D_Drmmr, to create your own class to bundle the controls for each channel. I'd probably do that myself in the form of an EQ band control class, derived from Panel or even GroupBox. That would be some additional effort up-front but is likely to pay later by simplifying things.

---

I know how to access controls from a class but that's not the same thing as encapsulating (or "wrapping") is it.
"Add component class" (project menu) looked promising with designer code section in .h but no meaningfull designer view and I can't find any help on what this is or how to use it. Tried to search this forum but... (it still seems to be working on my first search...:rolleyes:)
RD

Quote:

---

Originally Posted by Eri523

[about C-style casts] I personally do use them, but rather rarely, and then mostly in the context of calls to native API functions. And the reason why I try to avoid them is not a "codiquette" one; it's because (at least to me) it's somewhat obscure what they actually do in C++[/CLI]: Depending on context, they sometimes behave like a static_cast and sometimes like a reinterpret_cast, and probably there are some more variants that don't come to mind now.

---

You probably know my position from before: if a simple cast is the goal, I don't see what's the big deal; if some byte-gymnastics needs to be done, that is, if there's some reason to use specific function-style cast, then go for it. I just don't see the point in the idea that code containing C-style casts should be turned down, or that the students should be sanctioned for using them - and I've seen such comments on the forums.

Quote:

---

Originally Posted by Eri523

Congrats to 1k posts, BTW! :thumb:

---

Wow, didn't even notice :D.

Quote:

---

Originally Posted by RogerD

I'm on my first VC project so followed this thread with avid interest.:thumb:

What I would appreciate is one or more pointers to info on how to achieve what has been hinted at here, namely encapsulating controls in a class.

I know how to access controls from a class but that's not the same thing as encapsulating (or "wrapping") is it.
"Add component class" (project menu) looked promising with designer code section in .h but no meaningfull designer view and I can't find any help on what this is or how to use it. Tried to search this forum but... (it still seems to be working on my first search...:rolleyes:)
RD

---

Well, the idea itself is not very complicated. Without encapsulation into a specialized control, what really happens is: the existing container controls, like panels, group boxes, or even forms themselves, are designed to accept other controls, so you can simply throw a bunch of labels, buttons, textboxes, or more complicated, composite controls, to create various UIs. But, if you have a lot of them, this method quickly becomes too much to handle.

Now, encapsulation may sound scary, but it an important OO principle which simply means that the internal workings of a class should be invisible to the outside world (the code that uses the class), so that they [internal workings (a.k.a. implementation)] can later be changed (say, improved), if required, without affecting the client code (the code that uses the class). For example, even if you have a bunch of controls on your form, none of them are available to another, different form you might have in your application - because each form should deal only with it's own set of controls.

To encapsulate a bunch of controls into something like an equalizer control, basically means to create a new control class, that will have it's own internal subcontrols, and that will then serve as a sort of a prefab custom composite control you can just drag onto your form just like you would do with a button or a combo box. If you need more than one, no problem - just drag another one. So, it's a neat thing. It handles the complexity by localizing certain responsibilities into certain places. The form handles button clicks, showing and hiding, communication, and such, but its the custom equalizer control that handles equalizer-specific behavior. The parent form has pretty much nothing to do with it.

But, there must be a way for the form and the custom control to communicate, without violating each others' privacy. This is done through well designed public methods (a.k.a. the public interface). This way, each class essentially says to the outside code "OK, these are the things I support and can do", and also, this enables each class to perform safety checks, handle invalid input, and similar. It is the public interface that enables the internals to change without affecting existing code - as long as a class does what it says it does, it doesn't matter how it does it (from the program correctness point of view - of course, it's better if the new way shows better performance).

OK. Now that we went over the basics, this is what you would do. You would create a Windows Forms Control Library project, and then you would be presented with a visual designer, where you would design your custom control. Just like when you create a new form, your custom control would be a class derived from an existing .NET class, in this case, the class in question is UserControl, which is really nothing more than an empty panel. Then, in the designer, you would drag a bunch of other readily available controls onto that panel, and arrange them in a certain way. Just like with a form, you would then add click handlers for buttons and/or other events, and do some work in them.
Then you would think about how this control should be used, and what information should be exposed to the outside world (and possibly received) from it. Based on this, you would create a public interface by adding some methods and properties. For example, for an equalizer control, you would provide a function (or a set of functions) for getting the values of each bar - so that the parent form can pass them on to the sound system. But anything equalizer specific (graph representation, color change effects as the bars are moved, presets, etc.) would be handled internally by the equalizer user control class, and wouldn't be available to the form. (Note that there's no form at this point, these are all simply considerations related to the fact that the user control will ultimately end up on a form.)
Once design and implementation are done, you would then create a windows forms application, as usual. You would then add a project reference to the user control library you just made, just like you would add a reference to any other .NET library. Now, I don't know the details in C++/CLI, but your user control should then appear on the toolbox, and you would simply drag it onto the form. If not, then you would be able to create it directly in code.

Quote:

---

Originally Posted by TheGreatCthulhu

[Re 1k posts]

Wow, didn't even notice :D.

---

:lol: Just like the last post count milestone I congratulated you to: #600 on July 10th last year (for history freaks: documented in our profile visitor message exchange - actually, I had to look it up there myself). Interestingly, even your choice of words was exactly the same back then... :D

Quote:

---

[...] You would create a Windows Forms Control Library project, and then you would be presented with a visual designer, where you would design your custom control. [...]

---

Oh, how I'd love to do that, but unfortunately there's no such project type for C++/CLI, at least not in the Express Edition. I also experimented with the "Add component class" menu item already mentioned by RD and various other stuff, all to no avail... :cry:

Quote:

---

[...] If not, then you would be able to create it directly in code.

---

And that's exactly what I have always done in this situation. I have created a little demo project with a really simple hand-coded aggregate control, to somewhat approximate the EQ band scenario. (Admittedly, one of the reasons for me to write it was that I [correctly, as I do know now] anticipated having fun doing it... :D) And now that you've laid out the fundamentals, perhaps it's even more instructive. (I hope I haven't violated the design recommendations you proposed correctly too much... :rolleyes:)

This is what the demo looks like (of course the traffic light is the handcrafted control):

Attachment 30537

(The bitmap images used in the demo are based on http://en.wikipedia.org/wiki/File:Traffic_light.gif.)

And this is the code of the TrafficLight control:

Code:

---

// TrafficLight.h
// Demo control class header file

#pragma once

namespace TrafficLightDemo
{
using namespace System;
using namespace System::Windows::Forms;

[Flags]
public enum class TrafficLightState
{
  Dark = 0x00, Red = 0x01, Yellow = 0x02, Green = 0x04,
  RedYellow = Red | Yellow, GreenYellow = Green | Yellow
};

public ref class TrafficLight : public Panel
{
public:
  TrafficLight();

  void AdvanceCycle();

protected:
  virtual array<TrafficLightState> ^GetCycleArray();

private:
  PictureBox ^CreateLightPbx(String ^strFileName, int nTop);
  void LightPbxClickHandler(Object ^sender, EventArgs ^e);

public:
  property TrafficLightState State
  {
    TrafficLightState get();
    void set(TrafficLightState value);
  }

protected:
  // Entirely trivial property override implemented right here for brevity:

  virtual property Drawing::Size DefaultSize
  {
    Drawing::Size get() override
    {
      return Drawing::Size(47, 119);
    }
  }

private:
  PictureBox ^m_pbxRed;
  PictureBox ^m_pbxYellow;
  PictureBox ^m_pbxGreen;
  TrafficLightState m_state;
  array<TrafficLightState> ^m_atlsCycleArray;
  int m_nCycleIndex;
};

}

---

Code:

---

// TrafficLight.cpp
// Demo control class implementation file

#include "StdAfx.h"

#include "TrafficLight.h"

using namespace TrafficLightDemo;

using namespace System::Drawing;
using namespace System::IO;

TrafficLight::TrafficLight()
{
  // With relative file names like this, the program expects the image files in the current
  // working directory. This is the project directory (the one with the source files) when
  // it is started inside the VS IDE with default project settings.

  // The bitmap images used in this demo are based on
  // http://en.wikipedia.org/wiki/File:Traffic_light.gif

  BackgroundImage = Image::FromFile("TrafficLightDark.png");
  m_pbxRed = CreateLightPbx("LightRed.png", 7);
  m_pbxYellow = CreateLightPbx("LightYellow.png", 43);
  m_pbxGreen = CreateLightPbx("LightGreen.png", 79);
  m_atlsCycleArray = GetCycleArray();
}

PictureBox ^TrafficLight::CreateLightPbx(String ^strFileName, int nTop)
{
  PictureBox ^pbx = gcnew PictureBox;
  pbx->Image = Image::FromFile(strFileName);
  pbx->Name = Path::GetFileNameWithoutExtension(strFileName);
  pbx->SizeMode = PictureBoxSizeMode::AutoSize;
  pbx->Location = Point(0, nTop);
  pbx->Visible = false;
  Controls->Add(pbx);
  pbx->Click += gcnew EventHandler(this, &TrafficLight::LightPbxClickHandler);
  return pbx;
}

TrafficLightState TrafficLight::State::get()
{
  return m_state;
}

void TrafficLight::State::set(TrafficLightState value)
{
  m_state = value;
  m_pbxRed->Visible = value.HasFlag(TrafficLightState::Red);
  m_pbxYellow->Visible = value.HasFlag(TrafficLightState::Yellow);
  m_pbxGreen->Visible = value.HasFlag(TrafficLightState::Green);
}

void TrafficLight::LightPbxClickHandler(Object ^sender, EventArgs ^e)
{
  // Forward picture box clicks to the TrafficLight (i.e. myself)
  // because visible picture boxes are mouse-opaque:

  OnClick(e);
}

// This implementation returns a traffic light cycle as used in Germany.
// The function is declared protected virtual, so derived classes can
// override it to change the cycle.

array<TrafficLightState> ^TrafficLight::GetCycleArray()
{
  return gcnew array<TrafficLightState>{
      TrafficLightState::Green, TrafficLightState::Yellow,
      TrafficLightState::Red, TrafficLightState::RedYellow
    };
}

void TrafficLight::AdvanceCycle()
{
  m_nCycleIndex = (m_nCycleIndex + 1) % m_atlsCycleArray->Length;
  State = m_atlsCycleArray[m_nCycleIndex];
}

---

And here's the main form implementation file of the demo, making use of the control above:

Code:

---

// Form1.cpp

#include "stdafx.h"

#include "Form1.h"
#include "TrafficLight.h"

using namespace TrafficLightDemo;

System::Void Form1::Form1_Load(System::Object^  sender, System::EventArgs^  e)
{
  Point ptNextLocation = Point::Empty;
  EventHandler ^ehTrafficLightClick = gcnew EventHandler(this, &Form1::TrafficLightClickHandler);
  for (int i = 1; i <= 4; ++i) {
    TrafficLight ^trl = gcnew TrafficLight;
    trl->Name = String::Format("Traffic light {0}", i);
    if (ptNextLocation.IsEmpty)
      ptNextLocation = Point(trl->Margin.Left, trl->Margin.Top);
    else
      ptNextLocation.Offset(trl->Margin.Left, 0);
    trl->Location = ptNextLocation;
    trl->Click += ehTrafficLightClick;
    Controls->Add(trl);
    cbxLight->Items->Add(trl->Name);
    ptNextLocation = Point(trl->Right + trl->Margin.Right, trl->Top);
  }
  cbxLight->SelectedIndex = 0;
}

System::Void Form1::cbxState_SelectedIndexChanged(System::Object^  sender, System::EventArgs^  e)
{
  safe_cast<TrafficLight ^>(Controls[cbxLight->Text])->State =
    static_cast<TrafficLightState>(Enum::Parse(TrafficLightState::typeid, cbxState->Text));
}

System::Void Form1::cbxLight_SelectedIndexChanged(System::Object^  sender, System::EventArgs^  e)
{
  cbxState->Text = safe_cast<TrafficLight ^>(Controls[cbxLight->Text])->State.ToString();
  chkCycle->Checked = m_setTrafficLightsToCycle->Contains(cbxLight->Text);
}

void Form1::TrafficLightClickHandler(Object ^sender, EventArgs ^e)
{
  cbxLight->Text = safe_cast<TrafficLight ^>(sender)->Name;
}

System::Void Form1::chkCycle_CheckedChanged(System::Object^  sender, System::EventArgs^  e)
{
  if (chkCycle->Checked)
    m_setTrafficLightsToCycle->Add(cbxLight->Text);
  else
    m_setTrafficLightsToCycle->Remove(cbxLight->Text);
  cbxState->Enabled = !chkCycle->Checked;
}

System::Void Form1::tmrCycleState_Tick(System::Object^  sender, System::EventArgs^  e)
{
  for each (String ^strTrafficLight in m_setTrafficLightsToCycle) {
    TrafficLight ^trl = safe_cast<TrafficLight ^>(Controls[strTrafficLight]);
    trl->AdvanceCycle();
    if (trl->Name == cbxLight->Text)
      cbxState->Text = trl->State.ToString();
  }
}

---

I intentionally decided to leave the code mostly uncommented, because I think finding out what it can do by studying the code rather than documentaion is more instructive with respect to how it does this. All the functions are somewhere between small and tiny, so it shouldn't be too hard to understand. Most of the remaining complexity is most probably due to the inherent complexity of the subject.

Admittedly, there's also some "hidden complexity" due to cascading control interactions. I mainly think this just demonstrates how implementing stuff in terms of other stuff can surprisingly simplify things. Admittedly (again) such a design incurs some risk of trouble like infinite event recursion or counter-productive circular control state dependencies, but then again, nothing good comes for free... :cool:

I also attached a ZIP file of the demo project to this post.

Quote:

---

Originally Posted by Eri523

Oh, how I'd love to do that, but unfortunately there's no such project type for C++/CLI, at least not in the Express Edition. I also experimented with the "Add component class" menu item already mentioned by RD and various other stuff, all to no avail... :cry:

---

Oh. Right, that's a bit of a problem. In any case, your sample is a nice, understandable, compact demonstration of the concept that nicely complements all I said above. The fact that your custom control derives from Panel makes no difference, to clarify that for RogerD. For the same reason, I'd like to make a few comments, in order to connect your code to what I said in the previous post.
[hr]

@RogerD: About Public Interface vs Internal implementation using Eri523's Example Code
Internal implementation details mostly come down to the implementation of the State property (here, only the declaration is shown).

Code:

---

public:
  property TrafficLightState State
  {
    TrafficLightState get();
    void set(TrafficLightState value);
  }

---

The State property itself represents a part of the public interface (along with everything else declared public).
The important thing to note here is that, while the TrafficLight control itself contains 3 picture boxes, none of them is ever exposed to any code outside the class. What TrafficLight class does with those 3 picture boxes is a matter of internal affairs, to put it that way.
Note that the form only passes a TrafficLightState value, and only gets that value back, and the TrafficLight control updates its internal state (which picture box is shown, and at what time), without the form "knowing" anything about it, as you can see here.

Code:

---

System::Void Form1::cbxState_SelectedIndexChanged(System::Object^  sender, System::EventArgs^  e)
{
  safe_cast<TrafficLight ^>(Controls[cbxLight->Text])->State =
    static_cast<TrafficLightState>(Enum::Parse(TrafficLightState::typeid, cbxState->Text));
}

---

Or, if that's to cluttered, it's equivalent to:

Code:

---

System::Void Form1::cbxState_SelectedIndexChanged(System::Object^  sender, System::EventArgs^  e)
{
    TrafficLight ^currentTrafficLight = safe_cast<TrafficLight ^>(Controls[cbxLight->Text]);
    TrafficLightState selectedState = static_cast<TrafficLightState>(Enum::Parse(TrafficLightState::typeid, cbxState->Text));

    currentTrafficLight->State = selectedState;   
}

---

From the perspective of the form, it just works. This is good for two reasons. First, if a piece of code from the outside ever got a reference to one if the internal picture boxes, nothing could prevent that code to, say, set a smiley face image instead of a red light image. This violates the invariants of the TrafficLight class (which are in this context, roughly: only show the correct light, and nothing else). Second, once a public interface is established, the internals can change smoothly (maybe a better way of implementing is suddenly available, the control might be made more performant, etc.). For example, all those picture boxes can be entirely removed from the code, and the TrafficLight class can be modified to simply draw the traffic light image(s) onto its own surface - and no change would be required to the Form1 class, which is an example of the code that uses the TrafficLight class. All client code remains functional - the change is localized to the TrafficLight class.

One thing to note is that the events of the TrafficLight control (inherited from Panel) are also a part of the public interface.
So, the following peace of code is an example of how TrafficLight can communicate via an event that it has been clicked - the client code (Form1) class subscribes to an event, passing a callback method (which TrafficLight will then be able to call, in order to notify Form1):

Code:

---

EventHandler ^ehTrafficLightClick = gcnew EventHandler(this, &Form1::TrafficLightClickHandler);

// and then later...

trl->Click += ehTrafficLightClick; // the hook-up

---

Then Form1 implements what should happen on this notification (coordinates the behavior of controls on a higher level):

Code:

---

void Form1::TrafficLightClickHandler(Object ^sender, EventArgs ^e)
{
  cbxLight->Text = safe_cast<TrafficLight ^>(sender)->Name;  // updates the "Traffic light" combo box to the selected traffic light
}

---

So, the controls communicate (form to each of the TrafficLight-s and vice versa) through a well established public interface (a kind of a protocol, if you will), and never manipulate any private state other than their own.

That's an impressive response from TheGreatCthulhu and ERI523 :thumb::thumb:and sure to be very helpful to many other users. Maybe should have started a new thread!
Obviously the material here is going to take some digesting as there's a few features new to me but here a couple of silly questions for starters:
In TrafficLight.h what's the [Flags] there for? Seems to make no difference if I take it out but changing it to say [FlagsZ] throws C2337 which isn't a listed error. Is it important?
The demo project works as a stand-alone but the most obvious problem is that it doesn't appear to create a component (visible in designer)making it difficult to design UI. In fernando306's project for example it's necessary to leave a large blank area in designer for all the instantiated panels to be plugged in at run-time. Or am I missing a step?
Looking again at "Component Class" it certainly appears made-for-the-part with overloaded constructor ("for designer support"). I guess the reference to IContainer gives the class container properties without the neccessity of inheriting from an actual container (i.e, panel.) Maybe in the non-express versions this works in the way we want it to. I'm shooting in the dark here - hopefully managing to miss my foot! When I have learned a lot more than I know now maybe I will be able to make more informed guesses...
Thanks again,
RogerD

Quote:

---

Originally Posted by RogerD

[...] Maybe should have started a new thread!

---

I actually considered that, then decided against it because I thought it's still related. May have been a wrong decision, but I hope at least it's not blatantly wrong... :)

Quote:

---

In TrafficLight.h what's the [Flags] there for? Seems to make no difference if I take it out but changing it to say [FlagsZ] throws C2337 which isn't a listed error. Is it important?

---

Actually, in the given demo project as posted/uploaded, the FlagsAttribute probably does not have any observable effect at all. At least it serves as an indication that TrafficLightState is a bit flags enum, and it may have an important effect when the code is changed later. The attribute mostly (if not exclusively) influences how the [Try]Parse() and ToString() methods behave for the enum it is applied to. The MSDN documentation on the attribute is interesting and instructive, but it rather describes some bit flags best practices than what the attribute actually does.

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.

Quote:

---

The demo project works as a stand-alone but the most obvious problem is that it doesn't appear to create a component (visible in designer)making it difficult to design UI. In fernando306's project for example it's necessary to leave a large blank area in designer for all the instantiated panels to be plugged in at run-time. Or am I missing a step? [...]

---

No, I don't think you're missing anything. That's simply the way how to use this sort of roll-your-own controls (unless I'm missing something myself... :)). I have gotten used to it over time. Here's a real-life example:

Attachment 30545

The 7-segment digit in the Options dialog is a hand-coded control. Unlike TrafficLight it's not an aggregate control; it's derived from PictureBox (not entirely sure why actually, the class is in a stable state since quite some time now, could probably have derived it from Panel as well) and otherwise is entirely owner-drawn, except for the solid-colored background which is drawn by the base class. Using it together with Designer-created controls like here demands some sense of proportion, manual calculations and/or plain trial & error. I can perfectly live with that, however.

The actual stopwatch on the main form, OTOH, is an aggregate control, derived from Panel and comprising eight 7-segment digit controls, three 7-segment punctation controls (hand-written), four labels (plain System::Windows::Forms::Label) and two almost invisible indicators at the right end which basically are labels as well. All the other controls on that form are children of another (auto-sized) panel and have been placed there using Forms Designer. That panel is invisible to the user (actually, rather, its Visible property is true but it's not noticeable) and serves the sole programmatic purpose to group the controls to simplify size calculations and setting their positions. The actual size of the form and position of the panel are calculated and set up at runtime in the form's constructor. That's basically the other way to deal with this sort of hand-written controls.

Quote:

---

Looking again at "Component Class" it certainly appears made-for-the-part with overloaded constructor ("for designer support"). I guess the reference to IContainer gives the class container properties without the neccessity of inheriting from an actual container (i.e, panel.) Maybe in the non-express versions this works in the way we want it to. I'm shooting in the dark here - hopefully managing to miss my foot! When I have learned a lot more than I know now maybe I will be able to make more informed guesses...

---

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, 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.

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

Quote:

---

Originally Posted by Eri523

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 :blush: my internet access is limited to one dongle and my wife... :rolleyes:

Quote:

---

Originally Posted by Eri523

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":

Code:

---

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?

Quote:

---

Originally Posted by Eri523

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?

Quote:

---

The demo project works as a stand-alone but the most obvious problem is that it doesn't appear to create a component (visible in designer)making it difficult to design UI. In fernando306's project for example it's necessary to leave a large blank area in designer for all the instantiated panels to be plugged in at run-time. Or am I missing a step?

---

Just a question - I can't find a machine with the Express version of VS at the moment, but, do you mean that the custom control doesn't appear in the toolbox (so you have nowhere to drag it from), or that you can drag it onto the designer work area, but it doesn't "behave" properly (can't manipulate it the normal way)?

If it's the toolbox, maybe you can add it manually - if that option is available in Express (could be that you tried this already...): In Form Design View, rgt-click on an item or an empty area -> Choose items... -> Browse to the .NET DLL (compile first).

The Choose Toolbox Items dialog is apparently a bit funky, as it might refuse to appear if, say, a firewall prevents internet access (at least in my experience).

Oh right - the second option. The designer page is just like a normal form designer only without the form. Dragged components appear as an icon like the non-visual components e.g., timer and file dialog. Just click the icon to enter properties/events like in normal designer. Still have to manually enter
" this->Controls->Add(button1);" though (see prev post.) I think this is the visual component designer neutered for Express vs.
Thanks for advice tho - unfortunately there's nothing in rt-clk tho only an "arrange icons" etc seton b/g or a standard cut/copy/paste menu on the icon itself.
Looks like I might have to consider getting out the plastic...!

IIRC this is about as far I got with that myself, and then I asked myself what would be the real advantage of that over hand-coded aggregate controls... :ehh:

Before I go on to what I wanted to say in this post, another question: when you derive from Panel, what functionality does VS Express provide, in terms of visual design capabilities? Does it allow the customized panel to be dragged onto a Form on the design surface, does the panel appear normally, and is the panel's member variable created?

OK.
I only now see what's the confusion here (I think - frankly, I got a little lost in all the posts here).
So, let me first see if I got this right: you are experimenting with composite control programming (by this I mean a control that logically and visually contains other controls), and you are implementing IContainer, or deriving from Container in order to do this?

The problem is, Microsoft's naming of the classes is a little confusing here. The IContainer interface and it's ready-made implementation, the Container class, don't represent a composite control. The concept of "container" here represents a logical container (host) of components, where components are IComponent implementations, which, as you know, may or may not be controls, or may or may not have a visual representation (think timer components, DB-related components, etc...).

The idea behind components is that they, although not necessarily visual in nature, can be combined, modified, and reused in a way similar to the way controls are used for visual UI design (don't forget that controls are specializations of the Component class). Containers in this context are objects that contain (host) components, coordinate them and provide various services (like serialization, code generation, designer support, etc.). For example, the Windows Forms designer itself is a container that host design time versions of the controls, and other components.

Now, the .NET library also provides a base class for composite controls, called ContainerControl, and a corresponding interface, IContainerControl. ContainerControl derives indirectly from Control (so it inherits all the common functionality), and directly from ScrollableControl, so there's support for that. On its part, it adds some very basic composite control related functionality - namely, you can add child controls and set which one of them has focus.

This class is a base class for some other controls you often use, like Form, SplitContainer, ToolStripPanel, and more importantly in the context of this discussion, UserControl.

UserControl is the class you want to derive from if you want to make custom composite controls. The class itself is fully functional, but when not specialized, it's really nothing more than an empty panel, with an important difference.

While the Panel class is designed as a design-time drag & drop area, onto which controls can be added directly in the designer of the form, UserControl is not. UserControl itself can be designed, but in a separate designer window, where you can add child controls and fine tune the appearance of your customized composite control (this is what enables you to avoid adding buttons, labels, and other child controls manually in code). However, once compiled, when you go back to the form's design view, you can drop your user control onto the form, but the user control will not, by default, accept additional child controls through a drag & drop operation - and this is good; you're making a ready made product, you don't want any client code (or developer) to mess with your visual design.

This, at least in non-Express versions, makes the user control appear as any other control.

This also means that, once placed on the form, only one member variable will be added to the form's code - the member variable representing your user control. Variables representing subcontrols are not, and should not be added to the form's code, since the subcontrols are owned and manipulated by the user control itself (encapsulation). They are the responsibility of the user control. If you want client code to affect the internal state of the user control, you have to provide a public interface (methods/properties/events) through which this can happen. This way, the state-change logic remains encapsulated inside the user control.

If you want your user control to behave more like panel, see this. But usually, you don't - because what you're making is a well defined, reusable product, with a consistent appearance across different uses.

Note that Panel is not derived from ContainerControl - I suspect this decision has to do something with the way Panel is used at design time. When you drag & drop child controls onto the panel, it's the form that owns those child controls, and it's the form that manages their life time. Sure, panel propagates various events to them, but that's the extent of its responsibility. It's as if you're an electrical engineer, and your having fun with making circuits, adding AND and OR gates to the board to achieve certain functionality.

With UserControl is different: it's as if you made a product, closed it in a case (encapsulation), and the case provides input and output slots (interface) through which the product can be plugged into some machine designed to use it (client code / form), and you are ready to ship it.
Normally, users don't open the case and mess with the internal components.

So, try out deriving from UserControl, or even ContainerControl, and post back if the design-time experience is any different.

Quote:

---

Originally Posted by TheGreatCthulhu

Before I go on to what I wanted to say in this post, another question: when you derive from Panel, what functionality does VS Express provide, in terms of visual design capabilities? Does it allow the customized panel to be dragged onto a Form on the design surface, does the panel appear normally, and is the panel's member variable created?

---

No, none whatsover. In fact the only full designer support is for forms and the only built-in classes AFAICT are Forms, Component class mentioned before and very basic (non CLR) C++ class. As mentioned in a previous post Component class has limited designer support and all components dropped simply appear as icon (like e.g. timer.)

Attachment 30595

I'm new to VisualC and /CLR so probably Eri523 will be able to give more detailed answer.

This is an example of Component class with one button added:

Code:

---

#pragma once

using namespace System;
using namespace System::ComponentModel;
using namespace System::Collections;
using namespace System::Diagnostics;


namespace EncapsTest {

  /// <summary>
  /// Summary for EQcontrol
  /// </summary>
  public ref class EQcontrol :  public System::ComponentModel::Component
  {
  public:
      EQcontrol(void)
      {
        InitializeComponent();
        //
        //TODO: Add the constructor code here
        //
      }
      EQcontrol(System::ComponentModel::IContainer ^container)
      {
        /// <summary>
        /// Required for Windows.Forms Class Composition Designer support
        /// </summary>

        container->Add(this);
        InitializeComponent();
      }

  protected:
      /// <summary>
      /// Clean up any resources being used.
      /// </summary>
      ~EQcontrol()
      {
        if (components)
        {
            delete components;
        }
      }
  private: System::Windows::Forms::Button^  button1;
  protected:

  private:
      /// <summary>
      /// Required designer variable.
      /// </summary>
      System::ComponentModel::Container ^components;

#pragma region Windows Form Designer generated code
      /// <summary>
      /// Required method for Designer support - do not modify
      /// the contents of this method with the code editor.
      /// </summary>
      void InitializeComponent(void)
      {
        this->button1 = (gcnew System::Windows::Forms::Button());
        //
        // button1
        //
        this->button1->Location = System::Drawing::Point(0, 0);
        this->button1->Name = L"button1";
        this->button1->Size = System::Drawing::Size(75, 23);
        this->button1->TabIndex = 0;
        this->button1->Text = L"button1";
        this->button1->UseVisualStyleBackColor = true;

      }
#pragma endregion
  };
}

---

hope this helps to make it clearer. NB: This is a purely experimental project inspired by ERI523's excellent example and is a "self learning exercise" (in encapsulation) for me so I don't want to be too specific here. The object at present is to create a composite class which encapsulates several controls (on a e.g. panel). The class is then instantiated several times (60 I think in the original project) to make up the complete control panel. Making re-usable controls I think is probably not possible in Express?

Quote:

---

Eri523
IIRC this is about as far I got with that myself, and then I asked myself what would be the real advantage of that over hand-coded aggregate controls...

---

Well I just created my own demo (using some of what I learned in this thread) and I definitely found this method to be easier than trying to tweak the components to fit the space by hand. I created a class and set it to derive from Panel. Then I added a form and put a panel onto it and assembled all the components and added the event handlers using the deisgner. Then I just lifted the designer code into the waiting class and removed the bits for the form designer and edited the panel name to the class name. Everything works fine (so far...) To make changes to the design I just copy the body of the designer code rather than the whole class.

This is the (WIP)

Code:

---

#define N_FADERS 4
System::Void Form1::Form1_Load(System::Object^  sender, System::EventArgs^  e)
{
  EventHandler ^ehTestHandler = gcnew EventHandler(this, &Form1::TestHandler);
  Faders = gcnew array<Fader^> (N_FADERS);
  for (int i = 0;i<N_FADERS;i++)
  {
      Faders[i] = gcnew Fader(this,i);
      Faders[i]->button1->Click += ehTestHandler;

      if(i==0)
        Faders[0]->Left = 3;
      else
        Faders[i]->Left = Faders[i-1]->Right+3;
      Faders[i]->Top = 3;
      tabPage1->Controls->Add(Faders[i]);
  }
}
// public methods...
//
System::Void Form1::Fader_trackBar1_MouseUp(int FaderID)
{
  textBox1->Text = String::Format("TrackBar{0}",FaderID+1);
  textBox2->Text = String::Format("Value = {0}",Faders[FaderID]->trackBar1->Value);
}
System::Void Form1::Fader_numericUpDown1_ValueChanged(int FaderID)
{
  textBox1->Text = String::Format("UpDownHi{0}",FaderID+1);
  textBox2->Text = String::Format("Value = {0}",Faders[FaderID]->numericUpDown1->Value);
}
System::Void Form1::Fader_numericUpDown2_ValueChanged(int FaderID)
{
  textBox1->Text = String::Format("UpDownLow{0}",FaderID+1);
  textBox2->Text = String::Format("Value = {0}",Faders[FaderID]->numericUpDown2->Value);
}
System::Void Form1::Fader_checkBox1_CheckedChanged(int FaderID)
{
  textBox1->Text = String::Format("CheckBox{0}",FaderID+1);
  textBox2->Text = String::Format("Checked = {0}",Faders[FaderID]->checkBox1->Checked);
}
System::Void Form1::button1_Click(System::Object^  sender, System::EventArgs^  e)
{
  int i = (int)numericUpDown1->Value;
  Faders[i]->textBox1->Text = textBox3->Text;
}
System::Void Form1::TestHandler(System::Object^  sender, System::EventArgs^  e)
{
  //        textBox1->Text = String::Format("Button1_{0}",static_cast<Fader>(sender)->FaderID);
  //        textBox2->Text = "Button pressed";
}
void Form1::TestEventH(int FaderID)
{
}

---

Which gives something like

Attachment 30597

You can probably see I am trying two approaches wrt passing changes back to Form1. The methods in Form1 are accessed from the individual class instances using the "this" and FaderID parameters passed in the constructor (this makes identifying the caller instances efficient.) The second method is to set the event handlers (callbacks?) to call Form1 directly but this means the controls have to be declared public. At present I am looking at using delegates to implement the callback. Would appreciate any comments as to which, if any, of these is the best with respect to best OO and encapsulation policies.
RD

OK, I downloaded Visual C++ 2010 Express so that I could see for myself, but I actually managed to use the designer normally; the question is, does this functionality somehow come from what I had previously installed, or is VS Express actually capable of doing this on it's own (and it appears to me that it should be). So I'm going to attach a VS 2010 Express project, so that you can try

Quote:

---

Originally Posted by RogerD

As mentioned in a previous post Component class has limited designer support and all components dropped simply appear as icon (like e.g. timer.)
Attachment 30595

---

And as I mentioned in my previous post, since the Container class and the Component class do not represent a UI control, this behavior is normal. All UI Controls derive from the Control class, which is a specialization of Component, so, all Controls are Components, but not vice versa.
The icon like appearance for the non-control components is expected.
EDIT: I just noticed that deriving from Panel results in the same component like behavior, because Panel is not "designable". But I have a hunch this default behavior can be changed. Just a sec.
EDIT1: I dunno, have to read up the docs a bit more - but there's probably a way to make a Panel-derived class appear as a designable control by applying some attributes, like DesignerAttribute and possibly DesignerCathegoryAttribute.


To exploit the capabilities of the control designer, you should derive from System::Windows::Forms::UserControl.

I'm going to both attach the project, and write the steps so that you can reproduce it independently.

Here goes (assuming there are only the 4 project types available when VC++ Express installs) - create a solution with two projects:

1. First create a simple Windows Form project, to be used as a test host window for the user control.
   This way, the win form app will be set as the startup project by default. Note: you might want the name the solution differently, to match the name of the dll project (the other project that will actually contain the code for the user control).
   New project > CLR > Windows Forms Application
2. Now create the class library (DLL) project:
   New project > CLR > Class Library > (make sure that "Add to solution" is selected from the dropdown, and not "Create new solution") > OK
3. Now add a Windows Form class to that project [the class library project].
   This is for convenience, and it'll be a form only temporarily - so give this class a name intended for the user control ("MyControl", "EQControl"...).
   Close the design view for that class, and open the code view.
4. Replace
   public ref class MyUserControl : public System::Windows::Forms::Form
   with
   public ref class MyUserControl : public System::Windows::Forms::UserControl
5. Build solution, then open the design view for the user control. A blank design surface should appear.
   Drag a bunch of controls on it from the toolbar. Build the project.
   http://farm9.staticflickr.com/8344/8...b9f0092c_b.jpg
6. Open the design view for the windows form test host (from the first project).
   Right-click on the toolbox, and pick "Choose items...". Wait for the Choose Toolbox Items show some mercy and finally appear, then browse to the compiled DLL for the user control.
   (Now, this one might be problematic, since I recall you told me you don't have that option - but it appears in my installation of VC++2010 Express :confused:)
   http://farm9.staticflickr.com/8480/8...4262b78d_b.jpg
7. Pick the DLL file and then press OK to close the Choose Toolbox Items dialog.
   The new toolbox item will appear under some category in the toolbox, depending on where you right-clicked.
   http://farm8.staticflickr.com/7134/8...684a5d69_z.jpg
8. Now you should be able to drag the user control from the toolbox onto the test form, and the user control should render properly.

Please let me know if this works out.
Here's the attachment: Attachment 30601

Quote:

---

Originally Posted by RogerD

I'm new to VisualC and /CLR so probably Eri523 will be able to give more detailed answer.

---

I'm afraid I don't, at least not at the moment. As I stated some posts above, this is about as far as I got with that myself, then ceased further research in that direction since I doubted the potential benefit. :o However, it looks like you proceeded beyond the point at which I gave up, so you may know some things I don't...

Quote:

---

hope this helps to make it clearer. [...]

---

Admittedly no, at least not to me and now. :o The second snippet from your post contains some method definitions that somewhat look like event handlers but don't have their usual signature. I can't really firmly put that into any context known to me. Your complete demo project probably would clarify some things, but I don't have seen a link to download it. Did I overlook something?

@TheGreatCthulhu: Your proposals look really promising and I'll try them out ASAP. Unfortunately I'm rather busy with one of my real-life apps currently, right now pursuing some nastily weird bug that keeps escaping from m grip. (Well, once I'll have caught it, it likely may turn out to actually have been rather simple, and I'll ask myself how that could take me several days; like so many times... ;))

IIRC in my earlier experiments I got up to item #6 in your post but then got stuck there because my custom control attempt simply didn't show up in the Choose Toolbox Items list. But perhaps that simply was because I chose the wrong base class - in case that matters, what it seems to do.

Mainly, this post is meant to give you both a brief ping back, since I'm rather busy at the time and didn't have much time for this issue. But if we eventually get that sorted out, this may become the best thread ever, at least from my subjective POV. :D However, it's already way cool right now... :thumb:

I just discovered something awesome: VC++ 2010 Express appears to support another feature of the non-express versions of VS, it's just not turned on by default!

Tools menu > Options...

In the Options window, pick the Windows Forms Designer node from the list on the left, then, at the bottom (Toolbox category), set the AutoToolboxPopulate option to True.

Now you can proceed as described in my previous post, steps 1 through 6, minus the manual toolbox setup part.
With the option turned on, once you create a UserControl-derived class and build it, it will automatically be added by the IDE to the toolbox, at the very top, under it's own category.

Quote:

---

Originally Posted by TheGreatCthulhu

With the option turned on, once you create a UserControl-derived class and build it, it will automatically be added by the IDE to the toolbox, at the very top, under it's own category.

---

Is that automatic toolbox addition confined to the solution from which I add the component then? For instance, most of my apps certainly wouldn't need a 7-seg digit class, even less a stopwatch component class. Otherwise I might prefer to explicitly disable that feature if it's enabled by default, to prevent the toolbox from getting polluted with custom control classes actually unrelated to most other projects.

(Actually, I put the stopwatch component into a DLL of which the stopwatch application is merely a client. That way I can use the component in other apps in any desired and supported way I like. While the stopwatch can be embedded as a control in any form, I currently don't make use of that feature in any of my apps. However, the stopwatch component also is capable of creating its own rudimentary form, and I make use of that feature by late-loading the component in a few of my apps where timing may be of interest in debugging. However, there's only one of my apps where even the release version does support that, and there the feature is activated by specifying the path to the stopwatch DLL in an undocumented app.config entry or simply copying the stopwatch DLL to the app directory. Rather expert stuff, so...)

Looks like I'm ruminating too much. Time to go to bed...

Quote:

---

Originally Posted by Eri523

Is that automatic toolbox addition confined to the solution from which I add the component then? For instance, most of my apps certainly wouldn't need a 7-seg digit class, even less a stopwatch component class. Otherwise I might prefer to explicitly disable that feature if it's enabled by default, to prevent the toolbox from getting polluted with custom control classes actually unrelated to most other projects.

---

Yes, the additional toolbox items should only appear if the user control project is part of the solution (and it will show only when a form designer is active). So there will be no toolbox pollution :D.

For referenced assemblies, you'll have to use the "Choose items..." option (or you can simply open a file explorer and drag the dll file onto the toolbox).

Quote:

---

Originally Posted by TheGreatCthulhu

Please let me know if this works out.

---

Aaargh! :eek: I tried again and it worked... :o I think I must have copied one of the other references like IContainerControl or maybe just a typo but when I replaced the declaration with:


public ref class Fader : public System::Windows::Forms::UserControl


it just worked... WOW :thumb: When it didn't work first time because I wasn't expecting it to be something so simple I just gave up. Most profuse apologies to all.


So in this context no need to create user controls/dll's just build the composite and use the class straight off. (see example project zip below)

Anyway what I was working on was the user interface as I wasn't happy with the methods like passing "this" from Form1 or using "owner" property. (this is really getting a bit off topic...) There has been some previous discussion on this subject but I haven't seen this method used before. It seems (to me) it may be more "correct" because it naturally avoids the circular inclusion problem and the neccessity of declaring methods as public. I think this is correct but prepared to be proven wrong.:) Hope someone wiser can spare the time to review and appraise this example. NB: my vs. of Winzip doesn't work on this Win7 PC and the free zipper I found is a bit strange as it won't let me zip from the top level folder :( so hope this can be reconstructed correctly (in "EncapsTest" folder originally.)

Attachment 30607

Many thanks for brilliant and unstinting help (as always)
RogerD

PS: still working through the earlier posts so may be a while before I can catch up... :)

I see what you did. Basically, the Fader class is relying mostly on delegates, which you use to model events, to communicate with client code.

That is not wrong, public events are a part of the public interface, but there are a few caveats - I'll get back to that later.
You also expose some data that's potentially interesting to client code through the Anno and EqValue properties.

In relation to your comment from the last post: having public methods is not wrong per se, it's just that public methods should be there for a reason - you don't want to expose some method used for some kind of internal calculation, or internal management, but you might have some public methods that would make sense for client code. For example, if your Fader control was animatable, and you could animate the position of the trackBar over time, you could declare a public Update(double timeElapsed) method as a legitimate part of the public interface.

Next, as buttons, checkboxes, and numericUpDowns are internal member variables of the Fader class, these should definitively be private! If some aspect of them needs to be exposed as well, it should be done through the public interface of Fader (you don't even have to expose the internal controls themselves, you translate requests back and forth in the same way as you did with events - in the Form1 class, you didn't hook up to the events of the actual controls, but to those of the Fader, and then Fader did the rest).

This is important, because if these are not made private, client code (like Form1 class) can directly access any of those variables and, for example, set them to nullptr or replace them completely with different controls of the same type, or worse, with controls derived from that type (and this can be dangerous, if the intentions of the developer are malicious)!

Now, about the events.
You were right to assume that events and delegates are pretty close concepts, if not the same. But, the way you implemented them now, they will not appear in the Properties window as events, and you'll not be able to use the Properties to assign event handlers in the same way you'd use it for other controls.

There's a special syntax for declaring events, and it looks like this:

Code:

---

delegate void ClickEventHandler( int, double );
delegate void DblClickEventHandler( String^ );

ref class SomeClass {
public:
  event ClickEventHandler^ OnClick;
  event DblClickEventHandler^ OnDblClick;
};

---

Under the hood, the event keyword implicitly creates what's known as event property; the concept is similar to the normal properties, except that the backing field is a variable of the specified delegate type.
You can also explicitly declare an event using the event property syntax, and explicitly control how exactly the event get's hooked up with it's handler(s), which is sometimes useful. See this for more detail.

Anyway, if events are declared like this, they will be treated by the IDE as... well, events.
Another thing is the signature of the event handler. While there's no requirement for the handlers to have the signature (Object^ sender, EventArgsType^ e), that is what most people would expect, although it's a bit of a drag to create all those EventArgs derived classes. Sometimes it's not required though, as the owning object might use public properties and/or methods of the Fader object to retrieve the data it wants, considering that the name of the event provides semantic context ("what is it that happened").

The .NET library provides some help in the form of the EventHandler<T> generic delegate (note: this is not a C++ template), which enables you to at least avoid delegate declarations, and declare your events like this:

event EventHandler<EventArgsType^>^ OnClick;

where EventArgsType^ is a EventArgs-derived class, at least by convention - it actually can be any type.

For example, the handler method for

event EventHandler<int>^ EqValueChanged;

would be

void MethodNamePlaceholder(Object^ sender, int faderID);

EDIT:
BTW, .Net generics aren't too hard to learn, and although they are not templates, they are similar in some ways - an important difference is that, while templates are resolved at compile time, generics are substituted with the actual types at runtime. There are some other significant differences, too. Here's a quick tutorial from CodeGuru.

Quote:

---

Originally Posted by TheGreatCthulhu

[...] where EventArgsType^ is a EventArgs-derived class, at least by convention - it actually can be any type.

---

Interesting; that seems to have changed from .NET 4 to 4.5 (the version your link points to). The .NET 4 version of the same MSDN page shows the signature with a constraint requiring the type argument to be an EventArgs derivate. Or is simply one of the two documentation pages wrong? :ehh:

You are right! Actually, I think I originally just wanted to write "EventArgs-derived class.", and to end the sentence there, but then I went to the documentation and noticed that there are no type constraints, so I added the second part (it felt a bit strange, but I didn't think much of it...).

I'm guessing that it's more likely that the 4.5 docs are wrong in that respect?

Anyway, I better correct that statement, so:

The handler method for

event EventHandler<EventArgsType^>^ EqValueChanged;

would be

void MethodNamePlaceholder(Object^ sender, EventArgsType^ e);

where EventArgsType is a class derived form EventArgs.

Quick reality check - under .NET 4 the first one compiles, the second one doesn't (error C3214):

Code:

---

public ref class TestClass
{
public:
  event EventHandler<EventArgs ^> ^TestEvent;
};

public ref class TestClass2
{
public:
  event EventHandler<int> ^TestEvent;
};

---

Don't have access to .NET 4.5 to check with that.

Quote:

---

Originally Posted by TheGreatCthulhu

Please let me know if this works out.

---

I tried this out but VC++ crashed at step 6 :eek: I tried the Auto load setting you mentioned later but that had no effect so I tried Choose items... on a new project/empty form - same result. 2 hours later after a windows update session (that took a couple of updater updates to get update working!) I started VC and it came up with last project which was the one I uploaded that I built with Component Class. There at the top of the toolbox was the component all ready and waiting to drag-drop... ! It looks as if Component class DOES work after all :cool: I will test tomorrow on a raw project.
RogerD
P.S. yes it certainly seems to work:- Project>Add new item>Component class. Somewhere in this thread, I'm sure, there's an explanation for why the class derives from System::ComponentModel::Component instead of System::Windows::Forms::UserControl...
EDIT:
So to recap for anyone else reading this - in the above example (and in the context of the original question) there's no need to create DLL and the extra project. Just add a Component class - Project>Add new item>Component class, inherit from System::Windows::Forms::UserControl (instead ofSystem::Windows::Forms::Form) , build it and if AutoToolboxPopulate is enabled the component appears on the toolbox. If you want to use it outside the project create the dll as above. (Or copy the class file(s). NB you can drag the dll onto the toolbox if that's any easier.)

Quote:

---

Originally Posted by TheGreatCthulhu

You are right! Actually, I think I originally just wanted to write "EventArgs-...

---

I'm a bit lost now! This is purely about the generic form which is restricted to the standard event signature (i.e. EventArgsType), right? If you want to use the non-standard parameters list you use the delegate?

I note that the original example

Code:

---

delegate void ClickEventHandler( int, double );

---

results in "empty" parameters (i.e. param0 for the int...) in the default handlers while

Code:

---

      delegate void ReadyEventHandler(int FaderID);
//results in
private: System::Void fader1_OnReady(System::Int32 FaderID) {}

---

which is a bit more useful.

Quote:

---

Originally Posted by RogerD

I'm a bit lost now! This is purely about the generic form which is restricted to the standard event signature (i.e. EventArgsType), right? If you want to use the non-standard parameters list you use the delegate?

---

Yeah, we were talking about the constraints specific to the EventHandler<T> generic delegate - but you can use any user defined delegate type.

Quote:

---

Originally Posted by RogerD

I note that the original example

Code:

---

delegate void ClickEventHandler( int, double );

---

results in "empty" parameters (i.e. param0 for the int...) in the default handlers while

Code:

---

      delegate void ReadyEventHandler(int FaderID);
//results in
private: System::Void fader1_OnReady(System::Int32 FaderID) {}

---

which is a bit more useful.

---

Are you talking about auto-generated code? In the example, I was just trying to explain the concept, but if you want to rely on code generation, then you should definitely provide parameter names. As you probably know, in C++ parameter names can be left out in function declarations, and even if they are there, the parameter names in function definition don't have to match - in order for the compiler to decide which function to call, the compiler has to know the signature, but variable names are not needed; they are simply there so that a human can refer to them inside the function, and to make the code more readable. Same thing for delegate declarations.

Well, I admit this is slightly OT, but the thread already is so versatile... :rolleyes:

Quote:

---

Originally Posted by TheGreatCthulhu

[...] As you probably know, in C++ parameter names can be left out in function declarations, and even if they are there, the parameter names in function definition don't have to match - in order for the compiler to decide which function to call, the compiler has to know the signature, but variable names are not needed; they are simply there so that a human can refer to them inside the function, and to make the code more readable. [...]

---

Yes, the compiler doesn't require them, and quite some time ago, due to plain laziness, I tended to omit parameter names in function declarations (except in a few cases where I used them to improve human readability). But not much later I found out that the debugger uses the prototype names of parameters in its valiable display (locals and auto window, probably watch window as well, but I use that quite rarely). So if you omit them, the debugger will display the parameters nameless, and at the latest that will get somewhat confusing/annoying as soon as you have more than one parameter of the same type in a single function's parameter list. So since found out about that, I'm giving names to all the parameters in my prototypes and also recommend doing that to others.

Quote:

---

Originally Posted by Eri523

So since found out about that, I'm giving names to all the parameters in my prototypes and also recommend doing that to others.

---

Oh, yes - I agree; especially for class member function declarations in header files, since these are a form of documentation for the class. Good parameter names should tell you what the function does, and what are the semantics of each parameter.

But for the purposes of code snippets in forum posts, when the context is clear from the discussion, i think it doesn't hurt to avoid some repetition, so I sometimes omit them.