Как правильно управлять панелями инструментов, меню и контекстно-зависимыми элементами?

Question

В настоящее время я занимаюсь разработкой приложения WinForms на C #, и мне нужны сведения о том, как управлять кнопками панели инструментов, меню и другими контекстно-зависимыми элементами. Какова лучшая практика для этого?

Я нашел статью ' Использование шаблонов проектирования для упрощения взаимосвязи между меню и элементами формы в .NET ' на MSDN, но я не уверен, что есть лучший способ, так как статья довольно старый (опубликован в 2002 году).

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

Answer 1

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

Хорошо спланированный объектно-ориентированный подход диктует, как управлять действиями, запускаемыми событиями, чтобы избежать дублирования или наложения кода.

Answer 2

Класс ToolStripManager имеет метод Merge, так что у вас могут быть любые дочерние формы / пользовательские элементы управления, которые предоставляют свои собственные ToolStrips, которые объединяются с панелью инструментов главной формы, когда они имеют фокус.

http://msdn.microsoft.com/en-us/library/5523fet0.aspx

Если вы используете MDI, вы также можете объединить пункты меню родительской и дочерней форм.

http://msdn.microsoft.com/en-us/library/ms404319%28VS.80%29.aspx

Answer 3

Конечно, вы можете найти очень полезный источник вдохновения в Microsoft Office, поскольку это где-то стандарт (стандарт?).

В зависимости от типа формы, которую вы используете, я думаю, вы могли бы установить некоторые основные правила, где, например, формы ввода данных будут иметь базовое меню, такое как validate \ quit \ refresh \ отказаться от \ print \ export to excel \ filter \ заказать по \ и т.д. Такие меню (назовем их " Standard ") будут идеально доступны в элементах управления "Файл" и \ или "Редактировать" и \ или "Просмотр", придерживаясь стандартных меню Office (даже Firefox использует это терминология).

Я бы посоветовал вам всегда отобразить это стандартное меню, даже если некоторые действия не всегда доступны для тех или иных форм. Просто представьте, что данные, содержащиеся в одной из ваших форм, не могут быть обновлены при определенных обстоятельствах: вы все равно можете отобразить отключенную версию значка «проверить» вместо того, чтобы сделать ее невидимой. Это определенно облегчит понимание конечного пользователя.

Как только этот стандартный список меню / опций будет создан, я полагаю, вы обнаружите два других основных семейства меню, меню " Подробности " и действия " * ". "Меню:

• Подробности Меню позволяют перемещаться через формы, доступ / отображение подчиненные формы / подмножества данных, такие как Элементы в заказе на покупку.
• Действие Меню позволяют выполнять определенные действия с данными, например, отправлять заказ на покупку.

Ваши различные меню должны быть доступны через панель команд и контекстно-зависимые ярлыки. Такие параметры, как «фильтр», можно сделать доступными на связанном уровне управления, а такие действия, как «Извлечь ПО», доступны только на уровне записи / формы.

Людям или группе людей будет разрешено или не разрешать открывать формы и / или выполнять определенные действия с этими формами

Для управления меню и правами у наших приложений есть «файл меню» по умолчанию на стороне клиента, а также таблицы «userGroup-forms» и «userGroup-actions» на стороне сервера.

• userGroup-формы таблица ссылок групп и формы и вид списка \ изменить права каждой группы.
• userGroup-actions таблица содержит истинное значение, когда группа имеет право на выполнение определенного действия

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

Мы явно здесь в объектно-ориентированном подходе, не так ли?