Алтернативный редактор меню на базе Tree view
Поддержка drag & drop как между элементами одного меню , так и между различными файлами меню , возможность задания опции color ,font и style и многое другое.
Требуется наличие ActiveX : MS Treeview Control 6 и MS Forms 2.0 ,VFP 9
Для установки скопируйте menudesigner.app в каталог Home(1) и подключите его командой _menudesigner=Home(1)+'menudesigner.app'
Загрузить Menu designer



Исправлено 1 раз(а). Последнее : Евгений Банщиков, 17.03.11 07:04

1) Исходники? Лицензия?
2) Неверно размещает подменю в меню первого уровня - вкладывает их друг в друга, вместо размещения на одном уровне. Видно даже на тривиальном Menu/QuickMenu. При том если всё "поправить", сохранить, а затем пересохранить в режиме "стандартного" меню - он аналогично испортит "вложенность подменю" уже и в самом стандартном построителе меню.
3) Кнопка "Menu Designer" не выглядит как кнопка - зачем было делать её единственную Hover-кнопкой
4) В штатном построителе сразу видно назначенное на элемент меню действие - может быть использовать грид-дерево, или хотя-бы в тексты узлов дописывать нечто типа "Вызов формы (DO FORM some)", "Вызов процедуры (Есть процедура)", "Копировать ()"
5) Авторедактирование текста узлов IMHO не удобно - вместо выделения узла постоянно входишь в редактирование заголовка. При том я не увидел поля для редактирования заголовка в самой "детальной карточке" узла.
6) Зря совсем отключил детальную карточку для сепараторов.
7) Кнопочки MoveUp/MoveDown для текущего узла думаю не помешали бы, ну или хотя-бы шорткаты для этих действий, не всегда удобно только лишь перетаскиванием пользоваться...

Igor Korolyov
1) Исходники? Лицензия?

Лицензия свободная - можно использовать , распостранять и копировать без ограничений.
Если кому то нужны исходники для "заточки" под себя - предоставлю по просьбе , никаких там особых ноу хау и секретов нет

Igor Korolyov
2) Неверно размещает подменю в меню первого уровня - вкладывает их друг в друга, вместо размещения на одном уровне. Видно даже на тривиальном Menu/QuickMenu. При том если всё "поправить", сохранить, а затем пересохранить в режиме "стандартного" меню - он аналогично испортит "вложенность подменю" уже и в самом стандартном построителе меню.

Вернее - это проявляется только на QuickMenu.
Баг исправил , хотя это скорее QuickMenu "Нарушает стандарты" - пишет Levelname вехнего уровня в нижнем регистре.

Igor Korolyov
3) Кнопка "Menu Designer" не выглядит как кнопка - зачем было делать её единственную Hover-кнопкой
4) В штатном построителе сразу видно назначенное на элемент меню действие - может быть использовать грид-дерево, или хотя-бы в тексты узлов дописывать нечто типа "Вызов формы (DO FORM some)", "Вызов процедуры (Есть процедура)", "Копировать ()"
5) Авторедактирование текста узлов IMHO не удобно - вместо выделения узла постоянно входишь в редактирование заголовка. При том я не увидел поля для редактирования заголовка в самой "детальной карточке" узла.

Это все вопросы предпочтения. Лично мне не нравится , когда вся инфа вывалена кучей - режет по глазам .Хотя иная точка зрения тоже имеет право на существование
По поводу показа действия - MS Tree не позволяет показывать колонки ,значит для реализации надо городить что то сложное. Или спец активх или грид подвязывать . А стоит ли результат такого усложнения?

Igor Korolyov
6) Зря совсем отключил детальную карточку для сепараторов.

В чем смысл открытия карточки для сепаратора ? Какие свойства ему можно присвоить ?

Igor Korolyov
7) Кнопочки MoveUp/MoveDown для текущего узла думаю не помешали бы, ну или хотя-бы шорткаты для этих действий, не всегда удобно только лишь перетаскиванием пользоваться...

В принципе согласен - будет удобнее работать



Исправлено 2 раз(а). Последнее : Евгений Банщиков, 17.03.11 19:04

А почему бы просто исходник не положить рядом с готовым app - кому надо, скачает. Я просто уже отошёл от фокса, но в своё время рисовал наброски своего редактора - правда я там занимался ТОЛЬКО "расширением" - т.е. не предполагалось даже создания узлов, лишь задание своих реквизитов для имеющихся (связанных с кастомизированным MenuLib) - при том они все как раз в поле Comments хранятся (структура mnx не меняется).

Баг не только на QuickMenu - я прежде всего на своём меню от одной старой проги попробовал. И в mnx LevelName соответствует Name соответствующей записи "подменю" (Objcode=0) - конечно же он не соответствует Name самого пункта вызывающего подменю (Objcode=77 непосредственно перед записью "подменю")... Другое дело, что там могут быть сепараторы с типом "подменю" (с пустым подменю, конечно) и тому подобные "вольности"

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

По сепаратору - т.к. у меня для менюлиба регулируется видимость пунктов, то и видимость сепараторов приходится регулировать. Грубо говоря, в Comments сидит служебная инфа типа "имени права которое должен иметь юзер чтобы видеть данный пункт". Это, конечно, не нужно для штатного статического меню, но я как раз с прицелом на "расширение" редактора под менюлиб смотрю

Из "визуального" - текстбокс с KeyLabel активиксовый что-ли, нет у него контекстного меню, и не масштабируется он у меня с экранным DPI=120 (текст по вертикали не полностью помещается).

Igor Korolyov
А почему бы просто исходник не положить рядом с готовым app - кому надо, скачает.

Мне просто будет лишняя работа по сборке архива проекта при обновлении app. Не думаю что найдется много желающих копаться в исходниках. Кому надо - отправлю по запросу.

Igor Korolyov
Баг не только на QuickMenu - я прежде всего на своём меню от одной старой проги попробовал. И в mnx LevelName соответствует Name соответствующей записи "подменю" (Objcode=0) - конечно же он не соответствует Name самого пункта вызывающего подменю (Objcode=77 непосредственно перед записью "подменю")... Другое дело, что там могут быть сепараторы с типом "подменю" (с пустым подменю, конечно) и тому подобные "вольности"

Буду призателен , если сбросишь мне это меню для теста на al_fa$mail.ru
Вообще там встречаются "сочетания" которые на мой взглят смысла не имеют , типа пустого меню без Item или popup в сепараторе.
Их я не вижу смысла сохранять.

Igor Korolyov
Про "лишнюю информацию" - во-первых уж само "действие" это далеко не лишнее, во-вторых я же предложил простой способ борьбы - выводить прямо в заголовок узла в каких-то разделителях текст команды, или текст о том что там есть процедура/назначен системный пункт. Конечно, при этом не получится править на автомате текст заголовка пункта меню прямо в дереве, но вот это я как раз считаю не очень полезной функциональностью (да и возможно это обходится, если использовать всё же "ручное" управление входом в редактирование).

В принципе возможность правки текста в узлах можно сделать опцией в настройках . Поле в форме правки сделаю доступным.
Доп инфу можно выводить в какой нибудь статус бар.

Igor Korolyov
По сепаратору - т.к. у меня для менюлиба регулируется видимость пунктов, то и видимость сепараторов приходится регулировать. Грубо говоря, в Comments сидит служебная инфа типа "имени права которое должен иметь юзер чтобы видеть данный пункт". Это, конечно, не нужно для штатного статического меню, но я как раз с прицелом на "расширение" редактора под менюлиб смотрю

Ok Открою возможность правки примечания для сепараторов

Igor Korolyov
Из "визуального" - текстбокс с KeyLabel активиксовый что-ли, нет у него контекстного меню, и не масштабируется он у меня с экранным DPI=120 (текст по вертикали не полностью помещается).

Растяжку добавлю. Это контрол из MS Forms ,его назначение быть визардом клавиш - подобно аналогу в стандартном десигнере.
Родной текстбокс многие сочетания клавиш не ловит.

В 1.6 нормально уже работает с этим меню - не перетасовывает

Всё же я бы предпочёл прямо в тексте узлов видеть назначенную команду, а заодно и "пустые" пункты выделять. Примерно вот так:
[attachment 11718 md_view.PNG]

Кроме того мелкие баги - табордер некрасив - прыгает кое где хаотично.
В текстбоксе "назначения хоткея" в любом случае не ловятся многие сочетания - те же буковки с Alt-ом например...

P.S. Я бы "записался" в кандидаты на получение исходника Гугло-мыло такое же как аккаунт, только с точкой посередине вместо пробела.

Igor Korolyov
Кроме того мелкие баги - табордер некрасив - прыгает кое где хаотично.

У данной поделки от MS оказался очень неприятный глюк в режиме Windowstate=2, заменил его на обычный label

Igor Korolyov
В текстбоксе "назначения хоткея" в любом случае не ловятся многие сочетания - те же буковки с Alt-ом например...

Сочетания с Alt ловятся нормально , в отличие от стандартного десигнера. Некоторые хоткеи глушит системное меню и форма не дает ввести комбинации с Tab , но их можно забить ручками .

Igor Korolyov
P.S. Я бы "записался" в кандидаты на получение исходника Гугло-мыло такое же как аккаунт, только с точкой посередине вместо пробела.

ok , отправил

Я бы чета свое написал - но так как все у меня пишется "ручками", то не актуально, уж не обессудь. Ну что-то вроде такого



Конечно можно было бы сделать визуально, а оно надо ?

piva
Я бы чета свое написал - но так как все у меня пишется "ручками", то не актуально, уж не обессудь. Ну что-то вроде такого
.Add(F_BAR,"Open","File","\<Открыть","F3",OP_OPEN,IMG_OPEN,"Изменить текущий документ",1,FACE_VIEW)
.Add(F_BAR,"Save","File","\<Записать","Ctrl+S",OP_SAVE,IMG_SAVE,"Записать изменения в документе",1,FACE_DOCUMENT)
[/code]

Конечно можно было бы сделать визуально, а оно надо ?

Не буду спорить - так тоже можно и даже нужно . Например я так делаю все контекстные меню. Но если работать с большим сложно разветвленным меню с кучей опций, которое часто модифицируется , то ручками все писать уже будет как то тоскливо . Хотя и тут тоже есть готовые решения , например тот же menulib от Mark Hall. Игорь как я понял его и использует . Но вобще мне десигнер ближе к сердцу ,он с моей ленью лучше сочетается

Менюлиб замечателен тем, что не противопоставляет "чисто програмный" и "визуальный" способы - т.е. с одной стороны при большом желании можно именно в чисто програмном стиле описать меню (в любом методе/процедуре программы, хоть всё разом, хоть по частям) - НО есть утилита которая парсит mnx и делает меню из него. Плюс утилита которая подобно genmenu создаёт "prg с командами создания меню" - только уже не DEFINE PAD - а менюлибовские "объектные" аналоги...

2 Евгений
Ну я и имел в виду что "занятые" текущим меню комбинации он и не ловит - хотя как по мне, так и не очень то это и важно. Действительно всегда можно руками набрать нужное
Про Label не понял - я писал про то что порядок обхода кнопок по Tab на главной форме не "стройный" не сверху-вниз и слева-навправо... Другие формы кстати не смотрел... Это сущая мелочь IMHO (тем более что крайне редко когда будет использоваться именно с клавиатуры выбор кнопок), но тем не менее некрасиво

Женя - тут спорить - даже и не нужно, просто у меня это не только меню, но и тулбар - потому там и фигурирует слово FACE (морда ), т.е. это описание компонент визуального взаимодействия, а в виде чего оно будет - это уже может зависеть от задачи ;)

piva
Женя - тут спорить - даже и не нужно, просто у меня это не только меню, но и тулбар - потому там и фигурирует слово FACE (морда ), т.е. это описание компонент визуального взаимодействия, а в виде чего оно будет - это уже может зависеть от задачи ;)

Я подобный подход использую на уровне формы. Класс определяет контестное меню, тулбар, кнопки и RightClick меню. Форма может быть использованна другой формой для получения каких либо данных (например выбор из справочника) и вызывающая форма должна иметь возможность перерисовать весь face вызываемой под свои нужды , и без такого класса тут не обойтись .

Igor Korolyov
Менюлиб замечателен тем, что не противопоставляет "чисто програмный" и "визуальный" способы - т.е. с одной стороны при большом желании можно именно в чисто програмном стиле описать меню (в любом методе/процедуре программы, хоть всё разом, хоть по частям) - НО есть утилита которая парсит mnx и делает меню из него. Плюс утилита которая подобно genmenu создаёт "prg с командами создания меню" - только уже не DEFINE PAD - а менюлибовские "объектные" аналоги...

Смотрел я на него , но мне в принципе нужно было сделать только возможность Visible итемов , решил обоитись малой кровью - переписал под свои нужды genmenu.

Igor Korolyov
Про Label не понял - я писал про то что порядок обхода кнопок по Tab на главной форме не "стройный" не сверху-вниз и слева-навправо... Другие формы кстати не смотрел... Это сущая мелочь IMHO (тем более что крайне редко когда будет использоваться именно с клавиатуры выбор кнопок), но тем не менее некрасиво

Я имел ввиду , что вынес показ доп инфы по итему в аналог стат бара (контейнер с label вверху справа) -там выводятся имена баров и меню , текст комманд и первая строчка процедур.



Исправлено 1 раз(а). Последнее : Евгений Банщиков, 19.03.11 06:54