Вход на сайт
.Net - Menu
1036
11.09.08 18:30
Ситуация такая :
- небольшой проектик на 15-20 формочек
- в каждой формочке наверху красуется менюшка-диспетчер запуска других форм.
- где-то на 95% менюшки повторяются
Вот сижу и думаю как это более-мение нормально реализовать.
Набивать менюху в каждой из форм - безобразное занятие...
Писать руками отдельный класс - тоже довольно тягомотно...
Сделать отдельный компонент - редактор свойств писать достаточно долго...
Сделать невидимую форму и на ней отредактировать менюху с последующим расшариванием оной?
Кто как решал подобные проблемы?
- небольшой проектик на 15-20 формочек
- в каждой формочке наверху красуется менюшка-диспетчер запуска других форм.
- где-то на 95% менюшки повторяются
Вот сижу и думаю как это более-мение нормально реализовать.
Набивать менюху в каждой из форм - безобразное занятие...
Писать руками отдельный класс - тоже довольно тягомотно...
Сделать отдельный компонент - редактор свойств писать достаточно долго...
Сделать невидимую форму и на ней отредактировать менюху с последующим расшариванием оной?
Кто как решал подобные проблемы?
NEW 12.09.08 16:50
в ответ Murr 11.09.08 18:30
Ладушки, все почитали, никто не занимался...
Сделал так.
Взял пустую форму и набил на ней менюшку. Полученный код вырезал и запихал в класс производный от MenuStrip... для упрощения изменений - порезал на функции... надо было бы, конечно, завернуть в классы... но это позднее - как генератор допишу...
Теперь придется думать как заставить это работать... У формы, в принципе, есть проперть MainMenuStrip... хммм... идея, видимо, была правильная - сформировать меню и посадить его на форму... Но как всегда у билли - форма понятия не имеет дано ли ей уже меню и эта проперть возвращает null... Мало того, даже присвоив новое меню этой проперти, надо еще поплясать вокруг с бубном из Controls.Remove() Controls.Add(), SuspendLayout() & PerformLayout()...
Сделал так.
Взял пустую форму и набил на ней менюшку. Полученный код вырезал и запихал в класс производный от MenuStrip... для упрощения изменений - порезал на функции... надо было бы, конечно, завернуть в классы... но это позднее - как генератор допишу...
Теперь придется думать как заставить это работать... У формы, в принципе, есть проперть MainMenuStrip... хммм... идея, видимо, была правильная - сформировать меню и посадить его на форму... Но как всегда у билли - форма понятия не имеет дано ли ей уже меню и эта проперть возвращает null... Мало того, даже присвоив новое меню этой проперти, надо еще поплясать вокруг с бубном из Controls.Remove() Controls.Add(), SuspendLayout() & PerformLayout()...
NEW 14.09.08 02:52
в ответ NikolaiB 13.09.08 22:28
а сделать форму с меню и от неë потом все остальные
-----
Это - не проблема. Проблемы всплывают потом. Например, взяв меню с одной формы и прицепив его к другой... имеем одну форму без меню... Если во второй было свое меню - имеем два меню... и т.п.
- разве не более быстрое решение?
-----
У меня получается что нет. Если наследоваться от какой-либо формы, а не прямо от Form, то надо думать как редактировать эти формы. Визуальный редактор без предкомпиляции базовой формы просто не будет работать...
-----
Это - не проблема. Проблемы всплывают потом. Например, взяв меню с одной формы и прицепив его к другой... имеем одну форму без меню... Если во второй было свое меню - имеем два меню... и т.п.
- разве не более быстрое решение?
-----
У меня получается что нет. Если наследоваться от какой-либо формы, а не прямо от Form, то надо думать как редактировать эти формы. Визуальный редактор без предкомпиляции базовой формы просто не будет работать...
NEW 31.10.08 12:25
в ответ Murr 14.09.08 02:52
У Билл при наследовании форм (а не везде ли вообще?
) не все в порядке. Но более-менее работает.
Во всяком случае мне как-то удавалось. Я делал формы наследники, правда не для меню, а для визардов.
А может можно пойти по такому пути - у Вас есть одна форма с меню, а все остальные формы - только панели, которые Вы "вручную" вставляете в нужный экземпляр формы при ее создании.
Тогда и меню только на одной форме, и все "формы" (точнее панели) легко в дизайнере редактировать.
Можно поити дальше и наплодить форм отнаследованных от меню-формы с уже вставленными панелями-содержаниями. Редактировать их будет нельзя (исключая размеры и прочии свойства верхнего уровня), да ведь и не недо.
Да и вообще, по моему это хороший тон - выносить отдельные куски/панели в отдельные классы и потом их собирать в нечто общее вручную или в дизайнере (когда что нужно).

Во всяком случае мне как-то удавалось. Я делал формы наследники, правда не для меню, а для визардов.
А может можно пойти по такому пути - у Вас есть одна форма с меню, а все остальные формы - только панели, которые Вы "вручную" вставляете в нужный экземпляр формы при ее создании.
Тогда и меню только на одной форме, и все "формы" (точнее панели) легко в дизайнере редактировать.
Можно поити дальше и наплодить форм отнаследованных от меню-формы с уже вставленными панелями-содержаниями. Редактировать их будет нельзя (исключая размеры и прочии свойства верхнего уровня), да ведь и не недо.
Да и вообще, по моему это хороший тон - выносить отдельные куски/панели в отдельные классы и потом их собирать в нечто общее вручную или в дизайнере (когда что нужно).
NEW 01.11.08 02:18
в ответ mickle_ak 31.10.08 12:25
Тогда и меню только на одной форме, и все "формы" (точнее панели) легко в дизайнере редактировать.
-----
Как идея - вполне приемлемо. Даже где-то интересно. Правда у меня есть ощущение, что на панельке будет меню...
А реализацию надо смотреть. Бо, насколько Я помню, там, у билли, во взаимодействии иерархических панелей нахомутано немало...
Можно поити дальше и наплодить форм отнаследованных от меню-формы
-----
Это опять упрется в проблему визуального редактирования потомков, если ее не оформить как базовый компонент.
это хороший тон
-----
Хммм... Если оценивать по трудоемкости - не очень. Всегда быстрее и проще накидать компонентов, подрихтовать по месту и прописать уже подготовленные свойства... но как раз это требует трудозатрат на начальном этапе.
-----
Как идея - вполне приемлемо. Даже где-то интересно. Правда у меня есть ощущение, что на панельке будет меню...
А реализацию надо смотреть. Бо, насколько Я помню, там, у билли, во взаимодействии иерархических панелей нахомутано немало...
Можно поити дальше и наплодить форм отнаследованных от меню-формы
-----
Это опять упрется в проблему визуального редактирования потомков, если ее не оформить как базовый компонент.
это хороший тон
-----
Хммм... Если оценивать по трудоемкости - не очень. Всегда быстрее и проще накидать компонентов, подрихтовать по месту и прописать уже подготовленные свойства... но как раз это требует трудозатрат на начальном этапе.
NEW 05.11.08 11:59
Первое, что приходит в голову - это сделать так, чтобы был ровно один метод в конечных формах, который параметризирует (изменяемые пункты меню + делегаты на методы-обработчики) объект, который автоматически сажает меню на формы. Соответственно, чтобы не прописывать этот объект каждый раз, унаследовать все формы от базовой, где и создаётся данный объект, сажающий меню на форму в OnLoad, параметризация которого (объекта) будет доступна в наследниках через необходимость имплементации метода созданного для этой цели интерфейса.
Второе, что приходит в голову: "Набивать менюху в каждой из форм - безобразное занятие...", собственно, зачем набивать? Клик на объекте-меню и копи-пасте в другие формы. Ах, да, кажецца (лень проверять) обработчики херятся.
Ну, и третье, что приходит в голову - не работать с формами, а сделать только одну, с меню, и размещать на ней UserControls - самый предпочтительный, на мой взгляд, вариант. Соответственно, механизм размещающий UC на родительской форме и сделать ответственным за изменениями меню. Опять же, для централизации подхода - этот механизм проверяет поддерживает ли UC определённый интерфейс и дёргает параметризирующий (для изменяемой части меню) метод из UC.
В ответ на:
Кто как решал подобные проблемы?
Кто как решал подобные проблемы?
Первое, что приходит в голову - это сделать так, чтобы был ровно один метод в конечных формах, который параметризирует (изменяемые пункты меню + делегаты на методы-обработчики) объект, который автоматически сажает меню на формы. Соответственно, чтобы не прописывать этот объект каждый раз, унаследовать все формы от базовой, где и создаётся данный объект, сажающий меню на форму в OnLoad, параметризация которого (объекта) будет доступна в наследниках через необходимость имплементации метода созданного для этой цели интерфейса.
Второе, что приходит в голову: "Набивать менюху в каждой из форм - безобразное занятие...", собственно, зачем набивать? Клик на объекте-меню и копи-пасте в другие формы. Ах, да, кажецца (лень проверять) обработчики херятся.
Ну, и третье, что приходит в голову - не работать с формами, а сделать только одну, с меню, и размещать на ней UserControls - самый предпочтительный, на мой взгляд, вариант. Соответственно, механизм размещающий UC на родительской форме и сделать ответственным за изменениями меню. Опять же, для централизации подхода - этот механизм проверяет поддерживает ли UC определённый интерфейс и дёргает параметризирующий (для изменяемой части меню) метод из UC.
Dropbox - средство синхронизации и бэкапа файлов.
NEW 06.11.08 04:17
в ответ voxel3d 05.11.08 11:59
унаследовать все формы от базовой
-----
Это уже рассматривалось - проблемы в визуальном редактированнии наследуемых форм.
ровно один метод в конечных формах
-----
Проще - класс. Именно так и сделал. Неудобства - довольно много однократной ручной работы...
обработчики херятся.
-----
Именно. Плюс, это надо умножить на 15-20... и нигде ничего не забыть... проще будет добавить пунктик по месту...
сделать только одну, с меню, и размещать на ней UserControls
-----
Да, можно. Форма, правда, получится довольно "тяжелая"... даже если на ней только управление пользовательскими контролами ( или фреймами или панелями)...
Тот вариант, который Я пока не пробовал и который кажется более-мение подходящим к данной ситуации;
- сделать фрейм с меню... в виде синглентона(?)
- прописать все обработчики
- сделать интерфейсик для получения меню
- одной-двумя строками сделать привязку меню из фрейма к форме...
-----
Это уже рассматривалось - проблемы в визуальном редактированнии наследуемых форм.
ровно один метод в конечных формах
-----
Проще - класс. Именно так и сделал. Неудобства - довольно много однократной ручной работы...
обработчики херятся.
-----
Именно. Плюс, это надо умножить на 15-20... и нигде ничего не забыть... проще будет добавить пунктик по месту...
сделать только одну, с меню, и размещать на ней UserControls
-----
Да, можно. Форма, правда, получится довольно "тяжелая"... даже если на ней только управление пользовательскими контролами ( или фреймами или панелями)...
Тот вариант, который Я пока не пробовал и который кажется более-мение подходящим к данной ситуации;
- сделать фрейм с меню... в виде синглентона(?)
- прописать все обработчики
- сделать интерфейсик для получения меню
- одной-двумя строками сделать привязку меню из фрейма к форме...
<--- nobody harmed
in this action -->
NEW 06.11.08 10:53
Это уже частность, ответ на вопрос: как именно реализовать привязку меню. Пара мыслей. Костыль в виде искусственно введённого фрейма, исключительно для того, чтобы получить "даблклик - в коде возникают строки обработчика", на мой взгляд, излишен. Руками эвент прописывается почти настолько же быстро.
Нет, не тяжёлая, наоборот, это будет самая лёгкая форма. Простой диспетчер, который только меняет фреймы на форме, дёргает из внутренней хэш-таблицы колбэки в зависимости от выбранного пункта меню и при смене UC обновляет информацию об изменяемой части меню, специфичной для данного UC. Ничего сложного и перегруженного, все пункты меню будут дёргать общий обработчик, который будет передавать в диспетчерский метод только уникальное имя пункта меню.
в ответ Murr 06.11.08 04:17
В ответ на:
Тот вариант, который Я пока не пробовал и который кажется более-мение подходящим к данной ситуации;
- сделать фрейм с меню... в виде синглентона(?)
- прописать все обработчики
- сделать интерфейсик для получения меню
- одной-двумя строками сделать привязку меню из фрейма к форме...
Тот вариант, который Я пока не пробовал и который кажется более-мение подходящим к данной ситуации;
- сделать фрейм с меню... в виде синглентона(?)
- прописать все обработчики
- сделать интерфейсик для получения меню
- одной-двумя строками сделать привязку меню из фрейма к форме...
Это уже частность, ответ на вопрос: как именно реализовать привязку меню. Пара мыслей. Костыль в виде искусственно введённого фрейма, исключительно для того, чтобы получить "даблклик - в коде возникают строки обработчика", на мой взгляд, излишен. Руками эвент прописывается почти настолько же быстро.
В ответ на:
Да, можно. Форма, правда, получится довольно "тяжелая"... даже если на ней только управление пользовательскими контролами ( или фреймами или панелями)...
Да, можно. Форма, правда, получится довольно "тяжелая"... даже если на ней только управление пользовательскими контролами ( или фреймами или панелями)...
Нет, не тяжёлая, наоборот, это будет самая лёгкая форма. Простой диспетчер, который только меняет фреймы на форме, дёргает из внутренней хэш-таблицы колбэки в зависимости от выбранного пункта меню и при смене UC обновляет информацию об изменяемой части меню, специфичной для данного UC. Ничего сложного и перегруженного, все пункты меню будут дёргать общий обработчик, который будет передавать в диспетчерский метод только уникальное имя пункта меню.
Dropbox - средство синхронизации и бэкапа файлов.
NEW 12.11.08 15:33
в ответ voxel3d 06.11.08 10:53
Руками эвент прописывается почти настолько же быстро.
-----
У меня - практически за то же время, но... это выпадает из обсуждаемой технологии - менюшка должна редактироваться обычным образом - через визуальный редактор. Вопрос только в том, как это удобнее сделать...
который только меняет фреймы на форме
-----
При фреймах? Особенно, если не озаботится тем, чтобы они создавались и _удалялись_ - геморой будет обеспечен... Особенно, если начнется писанина в стиле VB6 - "панелька жива, неактивна(в бэкграунде), но я сейчас в ней вот это вызову..."
-----
У меня - практически за то же время, но... это выпадает из обсуждаемой технологии - менюшка должна редактироваться обычным образом - через визуальный редактор. Вопрос только в том, как это удобнее сделать...
который только меняет фреймы на форме
-----
При фреймах? Особенно, если не озаботится тем, чтобы они создавались и _удалялись_ - геморой будет обеспечен... Особенно, если начнется писанина в стиле VB6 - "панелька жива, неактивна(в бэкграунде), но я сейчас в ней вот это вызову..."