[RESOLVED] Databinding radiobutton set

[TheBigB]

Hi,

I'm trying to create a databinding to a couple of radiobuttons.
The dataobject contains a integer representation of the radiobutton to be set.
So after doing some searching I found the suggestion to make a groupbox/panel, so I made one:

	public class RadioPanel : Panel, INotifyPropertyChanged
	{
		public event PropertyChangedEventHandler PropertyChanged;

		private int _selectedIndex = -1;
		private bool _cancelEvents = false;

		public int SelectedIndex
		{
			get	{ return this._selectedIndex; }
			set
			{
				this._cancelEvents = true;

				foreach (Control control in this.Controls)
				{
					if (control is RadioButton && control.Tag != null)
						if ((string)control.Tag == value.ToString())
							((RadioButton)control).Checked = true;
						else
							((RadioButton)control).Checked = false;
				}

				this._selectedIndex = value;

				this._cancelEvents = false;
			}
		}

		protected override void OnControlAdded(ControlEventArgs e)
		{
			base.OnControlAdded(e);
			if (e.Control is RadioButton)
				((RadioButton)e.Control).CheckedChanged += new EventHandler(CheckedChanged);

		}

		private void CheckedChanged(object sender, EventArgs e)
		{
			if (!this._cancelEvents && ((RadioButton)sender).Checked == true)
			{
				this.SelectedIndex = Convert.ToInt32(((RadioButton)sender).Tag);
				if (PropertyChanged != null)
					PropertyChanged(this, new PropertyChangedEventArgs("SelectedIndex"));
			}
		}
	}

The radiobuttons in the panel are given a tag representing their 'index'.
Upstream works great. I modify the value in the dataobject and it is represented by the according radiobutton.
But when I check a radiobutton it doesn't update the dataobject.

The databinding I'm using is the following:

this.optPriority.DataBindings.Add("SelectedIndex", this._myDataObject, "Priority", false, DataSourceUpdateMode.OnPropertyChanged);

It's driving me mad, because it does fire the PropertyChanged event when I debug it.

If anyone could shed some light on this, that would be awesome.
Thanks.

[stlaural]

Is optPriority an actual radio button or is it the radio button group ? I think your issue might comme from the databinding. Here's a possible solution on StackOverflow. I think it might be worth the look. He's pretty much doing what you are trying to achieve, but it looks to me like he is binding on each radiobutton, see the bottom of the answer.

Anyways, hope this helps.

[TheBigB]

Thanks for the reply.
optPriority is the button group.
That link is where I got the idea from, but it uses LINQ.
And it mentions

 radioGroup1.DataBindings.Add("Selected", Properties.Settings.Default, "selected1");

So that's not it either.

[TheBigB]

I haven't worked with databindings a lot, so I might be totally off, but this looks like pretty odd behavior to me:
- Breakpoint at PropertyChanged firing
- Breakpoint on setter and getter in data object
I'd expect the PropertyChanged in the control to invoke the setter, but it seems to call the getter after firing PropertyChanged.

I'm really confused..

[stlaural]

Yeah I don't have much experience with event handlers either.
I guess you already checked but:
Is your setter actually called by your CheckedChanged event handler ? and when the getter is called after firing PropertyChanged, is the returned value the good one, is it actually the value of the selected radio button ?

[TheBigB]

Which setter are you referring to? The one in the dataobject or the control?
After the PropertyChanged event has fired, the getter of the control returns the correct new value.
What I'm expecting because of the binding, is the getter of the dataobject also to return the new value. But it doesn't.

[TheBigB]

Got the little bugger.
I was building a sample project with the control to post here, but it turned out to work fine there.
So I started looking more carefully what on earth could be the problem.

Seems that I was using an enum for the dataobject property.
As stated in one of the stackoverflow answers, the built-in databinding is very weakly typed.
A little exception from it wouldn't have been inappropriate here.

Thanks anyway

[stlaural]

hehe that explains why it was so hard to find the bug