MDI/QWorkspace+разные типы документов., Как правильно спроектировать? Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Древовидный Переключить на: Стандартный Переключить на: Линейный

[trdm]

Планирую сделать множество разных "документов" в смысле управляемых QWorkspace дочерних окон,
в которых будет разнородное содержимое: текст, формы разных типов, таблицы.
Каждый из типов документов имеет свои уникальные действия.
У некоторых документов есть даже свои менюшки 1-го уровня и панели инструментов. В смысле не одна а несколько.
как мне правильно архитектурно скомпоновать их в интерфейс?
есть ли примеры, которые можно посмотреть?
зарезервировать в главном меню максимальное количество возможных меню и при смене активного чилда перестраивать менюшку?
Как быть со стандартными акциями типа "ЗАписать", "Вырезать", "вставить", "Поиск" и т.п.
Сделать абстрактный класс МидиЧилд, добавить в него политики, типа
// политика доступности определенных действий для документов
// т.е. действие доступно: Всегда, Никогда, Запрос на доступность.
typedef enum _docActionPolicy {
actPolisyAlways
, actPolisyNever
, actPolisyAsk
} docActionPolicy;
в базовом заглушить их, а в наследнике разрешать только доступные/реализованные?
Вобщем кучка вопросов, на которых непонятно как правильно ответить (
Поможете?

[ViGOur]

Угу, но из одной общей для всех функции члена.

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

[trdm]

Угу, но из одной общей для всех функции члена.

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

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