Re: Поведение, когда нужно сделать выбор из нескольких макро
Posted: Sun 06 Jan, 2013 03:40
Latest post of the previous page:
Придумал - в Common макросе добавил область ShellFar Manager Forum
https://forum.farmanager.com/
Latest post of the previous page:
Придумал - в Common макросе добавил область Shellвнутри фара. при задании области коммон просто раскрывать макрос на все области.SUSim wrote:лучше оставить, а то перечислять очень много...
По-моему, не нужно.zg wrote:внутри фара. при задании области коммон просто раскрывать макрос на все области.SUSim wrote:лучше оставить, а то перечислять очень много...
Т.е. просто "перегрузить" обобщённое значение точным (как раньше) теперь нельзя.shmuel 13.01.2013 11:40:40 +0200 - build 3078 wrote:Code: Select all
1.4. Спецификации ключей не имеют приоритетов друг перед другом. Если есть макросы 1 (key="RCtrlX"), 2 (key="CtrlX") и 3 (key="/.CtrlX/"), то при нажатии RCtrlX все они будут рассматриваться на одинаковых основаниях, а выбор будет производиться по совокупности заданных полей: flags (включая возможный вызов callback для макросов MCTL_ADDMACRO), condition и priority.
Этот механизм убран, потому что получалось слишком много механизмов, а условия или приоритеты успешно решают эту же задачу.John Doe wrote:Т.е. просто "перегрузить" обобщённое значение точным (как раньше) теперь нельзя.
Нет больше такого механизма.
Надо использовать приоритеты (или условия).
Это актуально только для плагинописателей. Плагин может добавить макросы во время своей работы (см. MCTL_ADDMACRO), а callback в этом случае является аналогом condition (только он не на Lua, а на C, Pascal и т.п.).John Doe wrote:Но что такое этот callback?
Т.е. поведение по умолчанию не изменилось, и например макрос из Shell перекроет Common.shmuel 13.01.2013 11:40:40 +0200 - build 3078 wrote:Code: Select all
1.6. Макросы, назначенные на область "Common", имеют приоритет по умолчанию = 40.
Живое появилось, и хотелось бы поговорить конкретнее.Shmuel wrote:Со стороны это может показаться так. Детально объяснять сейчас нет времени. Когда что-то живое появится, можно будет говорить конкретнее.John Doe wrote:Зачем множить сущности?
Я вижу только усложнение.
Макросы, записываемые с клавиатуры, выделены в отдельную сущность, поскольку, в отличие от "стационарных" макросов, они:John Doe wrote:Зачем понадобилась новая отдельная сущность, да ещё и с собственным форматом?
Почему бы не продолжать хранить их как раньше и в прежнем формате?
Да, они более чем существенны - при удалении или модификации этих макросов. Не исключено, что поля "area" и "key" будут вообще убраны из содержимого этих файлов, а останутся только в имени.NightRoman wrote:Мне только интересно из любопытства - имена файлов клавиатурных макросов существенны?
Правильно ли я понимаю, что основная причина выделения их в отдельную сущность состоит в том, что реализация "write" для стационарных проблематична?1. Являются "read-write" (стационарные являются "read-only").
Будь они в одном формате - это существенно упростило бы такой перенос.Если такой макрос оказался полезным в долговременном плане (что бывает редко), его следует сделать стационарным.
Да, это я и имел в виду. Если инфа в имени файла, то внутри как-то некошерно повторять. (Но это так, типа дублирование *почти* всегда плохо).Да, они более чем существенны - при удалении или модификации этих макросов. Не исключено, что поля "area" и "key" будут вообще убраны из содержимого этих файлов, а останутся только в имени.
Реализация "write" для стационарных просто не нужна. Открывается редактор, в нём эта функциональность уже имеется.John Doe wrote:Правильно ли я понимаю, что основная причина выделения их в отдельную сущность состоит в том, что реализация "write" для стационарных проблематична?1. Являются "read-write" (стационарные являются "read-only").
Согласен, но поскольку данные макросы обычно короткие и простые, а необходимость в переносе возникает редко, то и проблемы как бы нет.John Doe wrote:Будь они в одном формате - это существенно упростило бы такой перенос.Если такой макрос оказался полезным в долговременном плане (что бывает редко), его следует сделать стационарным.
Как-бы нужна.Shmuel wrote:Реализация "write" для стационарных просто не нужна. Открывается редактор, в нём эта функциональность уже имеется.John Doe wrote:Правильно ли я понимаю, что основная причина выделения их в отдельную сущность состоит в том, что реализация "write" для стационарных проблематична?1. Являются "read-write" (стационарные являются "read-only").
Многие сложные макросы начинаются с простого.Shmuel wrote:Согласен, но поскольку данные макросы обычно короткие и простые, а необходимость в переносе возникает редко, то и проблемы как бы нет.John Doe wrote:Будь они в одном формате - это существенно упростило бы такой перенос.
Может быть, ну и что. Много чего в Фаре хочется еще, "что б само".В идеале хочется нажать клавишу, получить список назначенных на неё макросов, и чтобы редактор открылся с нужным файлом, и в нужном месте.
Да и вообще удобно начинать макрос с клавиатуры, чтобы фар создал "шаблон". Особенно для неподготовленного пользователя