Да проще некуда. В чем вообще проблем то возникает?
public partial class TestForm : Form
{
public delegate object InteractionEventHandler(object sender, object data);
public event InteractionEventHandler InteractionEvent;
public TestForm()
{
InitializeComponent();
}
private void comboBox1_SelectedIndexChanged(object sender, EventArgs e)
{
var res = InteractionEvent?.Invoke(this, new object[] { comboBox1.SelectedItem, DateTime.Now.ToString() });
if(res is object[] odat)
{
textBox1.Text = odat.Select(s=>s.ToString()).Aggregate((a, b) => a += Environment.NewLine +b.ToString() );
}
}
}
object locker = new object();
List<TestForm> formsList = new List<TestForm>();
private void button1_Click(object sender, EventArgs e)
{
TestForm nForm = new TestForm();
nForm.FormClosing += (ox, ex) =>
{
lock (locker)
{
formsList.Remove(nForm);
}
};
nForm.InteractionEvent += (ox, data) =>
{
if (data is object[] odat)
{
if (int.TryParse(odat[0].ToString(), out int num))
{
// тут определяете любую логику обработки запросов с форм. И передаете любые данные.
return Enumerable.Repeat(odat[1].ToString(), num).ToArray();
}
}
return null;
};
lock (locker)
{
formsList.Add(nForm);
nForm.Show();
}
}
Удивительно но да, нужно.
Странная логика. Ну и пусть меняет в классе параметров. Зачем постоянно тыкать в пользователя формами?
Вообще если форм много то это очень плохо сказывается на юзабилити.
Формы существуют только для отображения параметров а не как носители настроек. То есть класс формы не должен содержать общих настроек. Тогда и не нужно будет создавать целую форму только для того чтобы проставить там путь к какому нибудь файлу конфига.
Не рекомендуется же файл дизайнера менять. Вся проблема задачи заключается в неправильной логике работы и это порождает какой то невообразимый набор костылей.
- Класс параметров должен быть самодостаточным и отдельным без какого либо GUI.
- Формы должны отображать параметры и предоставлять изменение и сохранение данных без создания дополнительных форм если они не нужны пользователю в этот момент.
- Количество форм лучше минимизировать и сгруппировать по какому нибудь признаку.
описываете все поля класса настроек с проверкой изменения
public class FSettings
{
int _startUpCounter = 0;
public int StartUpCounter
{
get { return _startUpCounter; }
set { var old = _startUpCounter; _startUpCounter = value; if (old != _startUpCounter) OnPropertyChange?.Invoke("StartUpCounter", _startUpCounter); }
}
public event OnChangeEvent OnPropertyChange;
public delegate void OnChangeEvent(string PropertyName, object PropertyValue);
}
А при создании формы подписываете на изменения:
public TestForm(FSettings set)
{
InitializeComponent();
locSet = set;
set.OnPropertyChange += Set_OnPropertyChange;
}
private void Set_OnPropertyChange(string PropertyName, object PropertyValue)
{
// при каждом изменении полей будет прилетать сообщение со значением. И можете обновлять свои поля как хотите. И каждый тип формы может обновлять именно свои значения.
textBox1.Text = "OnChange \"" + PropertyName + "\" = " + PropertyValue;
}
Если заморочится то можно каждому контролу задать специфичное имя или таг с названием свойства класса и в цикле производить поиск и установку. Тогда будет еще меньше кода и что самое главное не будет костылей.