Кто нибудь знает как сделать или кто нибудь может привести код панели задач для открытых MDI форм? (пример приведен на рисунке).

Здравствуйте, bajik, Вы писали:

B>Кто нибудь знает как сделать или кто нибудь может привести код панели задач для открытых MDI форм? (пример приведен на рисунке).

Панель на главной форме. все дочернии формы наследуются от какой-то базовой формы, которая имеет перечень методов. при нажатии на кнопку панели вызывается метод дочернего объекта приведенного к базовому. Опеределить, какая форма ща активна я думаю не Вы знаете.

Здравствуйте, mrjeka, Вы писали:

B>>Кто нибудь знает как сделать или кто нибудь может привести код панели задач для открытых MDI форм? (пример приведен на рисунке).

M>Панель на главной форме. все дочернии формы наследуются от какой-то базовой формы, которая имеет перечень методов. при нажатии на кнопку панели вызывается метод дочернего объекта приведенного к базовому. Опеределить, какая форма ща активна я думаю не Вы знаете.

Выделенное ни разу не обязательно. Лучше немного подумать и обойтись без такого жёсткого ограничения.

Здравствуйте, mrjeka, Вы писали:

M>Панель на главной форме. все дочернии формы наследуются от какой-то базовой формы, которая имеет перечень методов. при нажатии на кнопку панели вызывается метод дочернего объекта приведенного к базовому. Опеределить, какая форма ща активна я думаю не Вы знаете.

Хотелось бы посмотреть какой то код, для наглядности. теоритически я понимаю как сделать:

1. Создать проект на основе шаблона стандартного MDI-приложения. Сделать у главной формы-контейнера пункты меню, какие необходимо и написать обработчики событий для каждого пункта. Например, при выборе пункта "Файл->Новый" должен создаваться и отображаться новый экземпляр дочерней формы (на основе единого шаблона для дочерних форм, см. п.2).

2. Создать шаблон дочерней формы, на основе которого будут создаваться все дочерние окна. Стандартные события, скорее всего, не подойдут, придется написать собственные события, которые должны передавать дополнительную информацию о каждом экземпляре дочерней формы (например, название и номер этой формы). Форма должна генерировать события, когда она впервые появляется на экране, когда на ней щелкают, когда ее сворачивают и т. д.

3. В главное окно-контейнер добавить стандартный компонент ToolStripBar, который будет работать аналогично панели задач (TaskBar) Windows. Этот тулбар позволяет динамически (программно) создавать на себе кнопки. Задача — программно добавить кнопку, когда создается новая дочерняя форма, удалять кнопку, когда форма закрывается, подсвечивать нужную кнопку, когда юзер активизирует форму. Нужно также обрабатывать события кнопок тулбара — активизировать соответствующую форму, когда юзер щелкает на кнопке.

4. Обмен сообщениями от дочерних форм и к тулбару и обратно выполняется в основном через главную форму. Это значит, что главная форма должна подписаться на соответствующие события дочерних форм и тулбара, и при получении сообщений о таких событиях вызывать для них соответствующие функции-обработчики (написать которые — ваш священный долг).

Здравствуйте, _FRED_, Вы писали:
_FR>Выделенное ни разу не обязательно. Лучше немного подумать и обойтись без такого жёсткого ограничения.

Я и не утверждал что это обязательно. Хотели пример — получили.

Но если не базовая форма, то какой либо интерфейс для всех дочерних объектов. Или как Вы себе это представляете?

Здравствуйте, mrjeka, Вы писали:

_FR>>Выделенное ни разу не обязательно. Лучше немного подумать и обойтись без такого жёсткого ограничения.
M>Я и не утверждал что это обязательно. Хотели пример — получили.

M>Но если не базовая форма, то какой либо интерфейс для всех дочерних объектов. Или как Вы себе это представляете?

И без интерфейса даже можно обойтись, реализовав соответствующий паттерн так, как, например, в Smart Client Software Factory (How to: Communicate Between Views).

Здравствуйте, _FRED_, Вы писали:

_FR>И без интерфейса даже можно обойтись, реализовав соответствующий паттерн так, как, например, в Smart Client Software Factory (How to: Communicate Between Views).

ok, это навигация, а как Вы вызовете метод (например Add) которого нет в дочернем объекте? Или это надо будет подходить каждому разработчику и говорить какие методы должны быть у каждого дочернего объекта?

Здравствуйте, mrjeka, Вы писали:

_FR>>И без интерфейса даже можно обойтись, реализовав соответствующий паттерн так, как, например, в Smart Client Software Factory (How to: Communicate Between Views).

M>ok, это навигация, а как Вы вызовете метод (например Add) которого нет в дочернем объекте? Или это надо будет подходить каждому разработчику и говорить какие методы должны быть у каждого дочернего объекта?

Если вызов метода Add не требуется для решения задачи топикстартера, то вызвать его можно как угодно.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, mrjeka, Вы писали:

_FR>Если вызов метода Add не требуется для решения задачи топикстартера, то вызвать его можно как угодно.
У топикастера тулбар с кнопками общий для всех дочерних окон.

Вот честно говоря не понятно. Допустим есть интерфейс

public interface IBaseForm
{
void Add();
void Edit();
void Delete();
}

каждая дочерняя форма наследует этот интерфейс.
В главной форме есть коллекция Collection<IBaseForm> childForms

При вызове соответствующих операций мне требуется просто найти активный chid в этой коллекции и вызвать у него метод
При этом нет необходимости думать, если ли он у него или нет.

А если вызывать "как угодно", то насколько это удобно?

Здравствуйте, mrjeka, Вы писали:

_FR>>Если вызов метода Add не требуется для решения задачи топикстартера, то вызвать его можно как угодно.
M>У топикастера тулбар с кнопками общий для всех дочерних окон.

Сведения достоверные? Шар протирали?

M>Вот честно говоря не понятно. Допустим есть интерфейс

M>public interface IBaseForm
M>{
M>void Add();
M>void Edit();
M>void Delete();
M>}

M>каждая дочерняя форма наследует этот интерфейс.

Это даже не ужас. Это Ужас-ужас-ужас.

M>В главной форме есть коллекция Collection<IBaseForm> childForms

Если мы говорим о Windows.Forms, то у формы уже есть Form[] MdiChildren и другого не надо.

M>При вызове соответствующих операций мне требуется просто найти активный chid в этой коллекции и вызвать у него метод
M>При этом нет необходимости думать, если ли он у него или нет.

С развитием приложения на тулбаре появляется десяток-другой кнопок, в интерфейсе такое же количество методов. Так же увеличивается и количество форм, реализующих интерфейс. Допустим так же до десятка или даже нескольких. Чего будет стоить добавление нового метода в такой интерфейс сможете сами представить?

При вашем подходе каждая форма знает обо всех командах (в том числе и о тех, что ей не нужны), в то время как гибким и расширяемым решением является то, при котором форма знает лишь о тех командах, которые ей нужны.

M>А если вызывать "как угодно", то насколько это удобно?

По реализации паттерна Command и на этом сайте достаточно информации, а во всё интернете и не счесть вовсе. Изучайте. Сравнивайте. Появятся конкретные вопросы — велкам в архитектуру.

Здравствуйте, _FRED_, Вы писали:

_FR>По реализации паттерна Command и на этом сайте достаточно информации, а во всё интернете и не счесть вовсе. Изучайте. Сравнивайте. Появятся конкретные вопросы — велкам в архитектуру.

Извиняюсь за тупость.
Да, паттерн Команда это замечательно. Но вот никак в ум не возьму как например реализовать команду Add для разных дочерних форм?
Если есть пример использования, вышлите кусок.

Я создал тулбар, кинул кнопку и указал ей команду AddCommand:AbstractCommand
Но у каждой из форм добавление подразумевает что-то своё. И где мне писать реализацию этой команды? и как?

Или дайте ссылки где почитать использование паттерна команда для подобных ситуаций.

Здравствуйте, mrjeka, Вы писали:

M>Здравствуйте, _FRED_, Вы писали:

_FR>>По реализации паттерна Command и на этом сайте достаточно информации, а во всё интернете и не счесть вовсе. Изучайте. Сравнивайте. Появятся конкретные вопросы — велкам в архитектуру.

Решение, которое приходит на ум. В каждой дочерней форме хранить коллекцию комманд, которые могут выполняться этой формой.
При добавлении дочерней формы парент должен читать список этих команд и энейблить/дизейблить соответствующие кнопки на тулбаре.

тогда: тулбар должен содержать все возможные кнопки (даже если их сотня)

В главной форме реализован паттерн команда, и всем кнопкам указана команда.

abstract class BaseCommand
{
   void Execute(); 
}
public class Add:BaseCommand
{
   override void Execute()
  {
    //Надо выполнять разные действия для разных форм!
  }
}
public class Edit:BaseCommand
{
   override void Execute()
  {
    //Надо выполнять разные действия для разных форм!
  }
}
public class Delete:BaseCommand
{
   override void Execute()
  {
    //Надо выполнять разные действия для разных форм!
  }
}

Приходит на ум следующее. Метод Execute переписать след. образом

abstract class BaseCommand
{
   public delegate void CommandMethodDlg(params object[] args);
   void Execute(); 
}
public class Add:BaseCommand
{
   override void Execute(CommandMethodDlg method)
  {
    method();
  }
}
public class Edit:BaseCommand
{
   override void Execute(CommandMethodDlg method)
  {
    method();
  }
}
public class Delete:BaseCommand
{
   override void Execute(CommandMethodDlg method)
  {
    method();
  }
}

а при вызове делегировать на выполнение команд сооветствующие методы активной формы.

На сколько криво? Только сильно не чмырите

Просто мне тоже очень интересно это решение. В свое время пробовал присобачить паттерн Команда к mdi приложению, но не нашел нормального подхода.