.NET (Core and Framework)

17-Oct-07 1:24

Hello,

I have an issue with a ComboBox control which I'll try to explain here.

On a windows form, I have Panel A. As a child control to Panel A I have another panel (Panel B). One of the children of Panel B is a ComboBox (ComboBox1).
- Panel A
- Panel B
- ComboBox1

The ComboBox1 is global to the form, since it's needed elsewhere on the code. If I set "ComboBox1.Parent = null" and then dispose of Panel B, the next time I create a new panel with our ComboBox1 inside, none of the ComboBox1 events will fire. Particularly, SelectedIndexChanged, DropDown, DropDownClosed.

It seems that because the parent of ComboBox1 was destroyed it somehow messes up some internal things inside ComboBox1.

Any ideas why this happens? Any suggestions to solve this? Is this a bug from Microsoft?

Luc Pattyn17-Oct-07 2:48

17-Oct-07 2:48

Hi,

if ComboBox1 is part of panelB, then there must be a panelB.Controls.Add(ComboBox1) somewhere.
if you want to remove panelB and reuse ComboBox1 elsewhere, say on panelC, then you must
execute a panelC.Controls.Add(ComboBox1).

Events get dispatched by the active form using its chain of Controls as it is set through
the Controls property. A Control that is not part of the Controls chain will not receive
events.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

this months tips:
- use PRE tags to preserve formatting when showing multi-line code snippets
- before you ask a question here, search CodeProject, then Google

tuga-x17-Oct-07 2:57

17-Oct-07 2:57

I apologise, I forgot to mention that ComboBox1 does not receive events even though it is part of another panel's controls collection.

So basically, when I destroy PanelB - ComboBox1 has no parent for a while - and then when I create another panel (PanelC), I assign ComboBox1.Parent = PancelC.

Events won't fire.

Luc Pattyn17-Oct-07 3:13

17-Oct-07 3:13

Hi,

I am not very familiar with the Parent property (I use it mainly when linking a dialog
to a parent form), so I am not sure ComboBox1.Parent = PanelC; is equivalent
to PanelC.Controls.Add(ComboBox1);

You could give it a try, if it does not help maybe you should publish relevant code.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

this months tips:
- use PRE tags to preserve formatting when showing multi-line code snippets
- before you ask a question here, search CodeProject, then Google

tuga-x17-Oct-07 3:45

17-Oct-07 3:45

Here's the partial class code for a proof of concept:

public partial class Form1 : Form
{
    Panel panela = new Panel();
    ComboBox comboBox1 = new ComboBox();

    public Form1()
    {
        InitializeComponent();

        this.panela.Name = "panel";
        this.panela.Size = new Size((int)(this.ClientSize.Width * 0.765), (int)(this.ClientSize.Height * 0.75));
        this.panela.BackColor = Color.SteelBlue;
        this.panela.Hide();
        this.panela.Parent = this;

        this.comboBox1.DropDownStyle = ComboBoxStyle.DropDownList;
        this.comboBox1.Items.AddRange(new string[] { "item1", "item2", "item3" });
        this.comboBox1.SelectedIndexChanged += new EventHandler(comboBox1_SelectedIndexChanged);
    }

    void button1_Click(object sender, EventArgs e)
    {
        this.panela.Location = new Point((this.ClientSize.Width / 2) - (this.panela.ClientSize.Width / 2), (this.ClientSize.Height / 2) - (this.panela.ClientSize.Height / 2));

        int width = (int)(this.panela.ClientSize.Width * 0.965);
        int height = (int)(this.panela.ClientSize.Height * 0.95);

        Panel panelb = new Panel();
        panelb.Size = new Size(width, height);
        panelb.Location = new Point((this.panela.ClientSize.Width / 2) - (width / 2), (this.panela.ClientSize.Height / 2) - (height / 2));
        panelb.BackColor = Color.White;

        Rectangle parentRect = panelb.ClientRectangle;
        int maxWidth = parentRect.Width - 4;

        this.comboBox1.Bounds = new Rectangle(parentRect.Left + 2, parentRect.Top + 2, maxWidth, this.comboBox1.Height);
        this.comboBox1.SelectedIndex = -1;
        this.comboBox1.Parent = panelb;

        Button ok = new Button();
        ok.Bounds = new Rectangle(parentRect.Width - ok.Width, parentRect.Bottom - ok.Height, 72, 23);
        ok.Text = "OK";
        ok.FlatStyle = FlatStyle.System;
        ok.Click += new EventHandler(ok_Click);
        ok.Parent = panelb;

        panelb.Parent = this.panela;

        this.panela.Show();
        this.panela.BringToFront();
    }

    void comboBox1_SelectedIndexChanged(object sender, EventArgs e)
    {
        MessageBox.Show("index changed");
    }

    void ok_Click(object sender, EventArgs e)
    {
        this.comboBox1.SelectedIndex = -1;

        this.panela.Hide();
        this.comboBox1.Parent.Controls.Remove(this.comboBox1);

        int count = this.panela.Controls.Count;
        int i = 0;
        while (i < count)
        {
            this.panela.Controls[0].Dispose();
            i++;
        }
    }
}

If instead of disposing the objects I use "this.panela.Controls.Clear()" the events will fire without any problem.

So it has to do with the Dispose() of the parent panel

Luc Pattyn17-Oct-07 14:53

17-Oct-07 14:53

Hi,

I have some problems with the last part of your code; the while loop continuously
calls Dispose() on the same Control, the first item in panela.Controls; I don't think
this is what you intended. The code resembles how one removes objects from a list,
but calling Dispose() does not remove things from a list, does it?

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

this months tips:
- use PRE tags to preserve formatting when showing multi-line code snippets
- before you ask a question here, search CodeProject, then Google

tuga-x17-Oct-07 23:02

17-Oct-07 23:02

By doing a Dispose() on the first control of the list removes it from the list automatically.

So, panela.Controls[0].Dispose() will remove the first control and dispose it. Next time it runs that code (panela.Controls[0].Dispose()) it will be a different control.

Luc Pattyn18-Oct-07 2:52

18-Oct-07 2:52

Hi,

indeed some strange things are happening here.
I did run your code (with some logging added) and it fails to trigger the combo events
from the second button click;
but when the OK button is clicked, when resetting the combo's index back to -1, it does
generate an event, even before panela is hidden, hence before anything really has changed.
So it seems like the combobox events, for unknown reasons, get temporarily disabled.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

this months tips:
- use PRE tags to preserve formatting when showing multi-line code snippets
- before you ask a question here, search CodeProject, then Google

tuga-x18-Oct-07 2:57

18-Oct-07 2:57

Ok, so I'm not hallucinating, something really strange is going on here.

I'm inclined to think it's a bug, but I don't really know.

Obviously there are ways around this, but I shouldn't have to do them. I'm not doing anything special!

Patrick Etc.18-Oct-07 9:16

Patrick Etc.

18-Oct-07 9:16

tuga-x wrote:
Ok, so I'm not hallucinating, something really strange is going on here.

I'm inclined to think it's a bug, but I don't really know.

Obviously there are ways around this, but I shouldn't have to do them. I'm not doing anything special!

It's not a bug, you're abusing the framework and relying on an implementation detail that may change, and HAS changed between .NET 2.0 and .NET 3.0.

The detail you're relying on is that calling Dispose() on a control causes it to be removed from its parent's control collection.

What you DON'T know is that that call also destroys the control's handle, which is why your events are no longer being received. The event model relies on the handle being created to raise events (or in most cases, even receive them from the operating system - how do you think the OS knows which control to send the event to?). Dispose() on a Control ALSO kills the handle's message loop - you know, that pesky little thing that is actually dispatching the Windows messages that allow your events to be raised.

If you want to remove the control from the parent collection, do that. Don't invent some convoluted system of destruction just to remove a control from the parent collection.

To add a control to panel B:

comboBox1.Parent = panelb;

To remove the control from panel B:

comboBox1.Parent = null;

You should not be calling dispose anywhere in your code. Anywhere. Dispose() is one of those functions that should almost never need to be explicitly used.

"If you think of yourselves as helpless and ineffectual, it is certain that you will create a despotic government to be your master. The wise despot, therefore, maintains among his subjects a popular sense that they are helpless and ineffectual."
- Frank Herbert

Luc Pattyn18-Oct-07 9:42

18-Oct-07 9:42

Hi Patrick,

I do agree with most of what you said.
I did not like the Dispose() calls either, but then the little mystery was the
combobox stopped, then resumed, getting events fired, and it was never disposed.
So while I did not like the code, I could not explain its behavior.

But what triggered me to react now was your statement: "Dispose() is one of those functions
that should almost never need to be explicitly used".

Well I have gotten the advice, and have been repeating it over and over, to "call
Dispose on instances you no longer need whenever the class offers Dispose()"; the rationale
is you don't know whether any unmanaged resources are being used (and how big the
managed ones could be), so it is best practice to call Dispose() when you're done with
an object. This is quite the opposite of what you write though. Care to elaborate?

[Added] I typically don't call dispose on controls, except for forms/dialogs, since
my controls tend to always be part of some Form, and I trust .NET to dispose properly
of the Controls that are used on a Form that gets Closed or Disposed.[/added]

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

this months tips:
- use PRE tags to preserve formatting when showing multi-line code snippets
- before you ask a question here, search CodeProject, then Google

Patrick Etc.18-Oct-07 9:56

Patrick Etc.

18-Oct-07 9:56

Luc Pattyn wrote:

[Added] I typically don't call dispose on controls, except for forms/dialogs, since
my controls tend to always be part of some Form, and I trust .NET to dispose properly
of the Controls that are used on a Form that gets Closed or Disposed.[/added]

I should have been more specific.. you shouldn't call Dispose on controls and GUIs. The framework is built to take care of that, and this example is proof enough of that. Dispose should only be called if the object is *really* never going to be needed again, which in this example is not true, and especially on desktop applications, is really an unnecessary code complication that will only lead to additional code to debug. (On CF applications, calling Dispose can be necessary because of the severely limited resources. Even so, I have never actually found it helpful or necessary to.)

Anywhere documentation tells you to call Dispose (Framework objects or 3rd party objects), you should call Dispose. For example I'm using a 3rd party serial port control that uses significant unmanaged resources and the application will lock up if they're not released.

Luc Pattyn18-Oct-07 10:41