Far.Cfg_Get

Здесь обсуждается всё, что касается макросов.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Re: Far.Cfg_Get

Post by John Doe »

Latest post of the previous page:

Smitis
Может быть вы обрисуете сценарий, в котором требуется обрабатывать неудачу?
https://t.me/FarManager — Telegram чат
User avatar
Smitis
Posts: 1709
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 23 times
Been thanked: 55 times

Re: Far.Cfg_Get

Post by Smitis »

John Doe wrote:Smitis
Может быть вы обрисуете сценарий, в котором требуется обрабатывать неудачу?
На предыдущей странице было.
Вообще, всё держится на том, что список параметров ФАРа фиксирован (почти, новые параметры всё равно появляются) и все отсутствующие параметры создаются при запуске ФАРа. А если эта концепция поменяется?
Разум когда-нибудь победит.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Re: Far.Cfg_Get

Post by John Doe »

Значит скрипты придется править, и nil не спасёт.
User avatar
zg
zero-gravity
Posts: 6016
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 185 times
Contact:

Re: Far.Cfg_Get

Post by zg »

Smitis wrote:и все отсутствующие параметры создаются при запуске ФАРа.
где создаются?
User avatar
Smitis
Posts: 1709
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 23 times
Been thanked: 55 times

Re: Far.Cfg_Get

Post by Smitis »

В таком случае бессмысленно возвращать значение tp - назавание параметра нам известно, его тип тоже.
zg wrote:где создаются?
В config.cpp
Разум когда-нибудь победит.
User avatar
zg
zero-gravity
Posts: 6016
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 185 times
Contact:

Re: Far.Cfg_Get

Post by zg »

Smitis wrote:В config.cpp
и в чём проблема. параметры фару нужны для работы, куда они могут деться?
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Re: Far.Cfg_Get

Post by John Doe »

Shmuel
Вот это замечание из Энциклопедии стоит оставить и для новой функции:
В процессе разработки Far Manager настройки (имена ключей и имена значений) могут меняться, добавляться и удаляться, поэтому Вы используете функцию на свой страх и риск. Поддержка функционала (имена ключей и имена значений) со стороны разработчиков не гарантирована.
User avatar
Smitis
Posts: 1709
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 23 times
Been thanked: 55 times

Re: Far.Cfg_Get

Post by Smitis »

В процессе разработки Far Manager настройки (имена ключей и имена значений) могут меняться, добавляться и удаляться, поэтому Вы используете функцию на свой страх и риск. Поддержка функционала (имена ключей и имена значений) со стороны разработчиков не гарантирована.
При таком подходе как раз и нужна проверка существования параметра. Первоначальный вариант ok, val, tp = Far.GetConfig (key, name) это как раз и предусматривал. А сейчас получается половинчатое решение - проверить функцией наличие параметра нельзя, зато есть малонужное значение tp, во-первых, тип параметра, так же, как и значение keyname, уже известны заранее, во-вторых, тип возвращаемого значения и так можно проверить через type.

П.С.
Имхо,
3-state -> 0,1,2 преобразуются соответственно в false,true,"other"
значения разного типа выглядят криво. Может проще оставить "как есть" 0,1,2? Тем более уже есть DM_GETCHECK и DM_SETCHECK именно так и работающие.
Разум когда-нибудь победит.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Re: Far.Cfg_Get

Post by John Doe »

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

tp действительно малонужное, но не мешает.
значения разного типа выглядят криво. Может проще оставить "как есть" 0,1,2?
Зато сейчас значения можно использовать в логических выражениях, да и в целом они соответствует тому, что мы видим в редакторе конфигурации.
User avatar
zg
zero-gravity
Posts: 6016
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 185 times
Contact:

Re: Far.Cfg_Get

Post by zg »

Smitis wrote:При таком подходе как раз и нужна проверка существования параметра.
зачем?
Shmuel
Posts: 6820
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 41 times
Been thanked: 528 times

Re: Far.Cfg_Get

Post by Shmuel »

Smitis wrote:Первоначальный вариант ok, val, tp = Far.GetConfig (key, name) это как раз и предусматривал. А сейчас получается половинчатое решение - проверить функцией наличие параметра нельзя
Как это нельзя, pcall пока ещё никто не отменял.
User avatar
Smitis
Posts: 1709
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 23 times
Been thanked: 55 times

Re: Far.Cfg_Get

Post by Smitis »

John Doe wrote:Зато сейчас значения можно использовать в логических выражениях, да и в целом они соответствует тому, что мы видим в редакторе конфигурации.
Я понимаю, что ОЧЕНЬ хочется чекбокс представлять как логическое значение. Сам с этим столкнулся в DialogClass. Но не получается представить ТРИ состояния ДВУМЯ значениями. У меня в DialogClass в результате этих терзаний появились два вида методов, одни работают с числовыми значениями, другие с логическими, причём последние мне категорически не нравятся, так как допускают неопределённость и я думал их убрать. Всё равно всё завязано на api где таких "логических" проблем нет.
Искуственная "трибитовая" (на три состояния) логика true, false, other напоминает древние примитивные системы счисления, типа один, два, много... А что делать, если ВДРУГ понадобится введение чекбоксов с состоянием больше чем три?
И, вообще, зачем придумывать лишние сущности? Тем более, что уже давно есть farapi с чекбоксами 0,1,2...
А то что отображается в редакторе конфигураций... Можно отображать, например, нефиг/нафиг/пофиг. Или цифрами племени Майя. К внутреннему представлению это никакого отношения не имеет.
Разум когда-нибудь победит.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Re: Far.Cfg_Get

Post by John Doe »

Smitis wrote:Я понимаю, что ОЧЕНЬ хочется чекбокс представлять как логическое значение.
Но не получается представить ТРИ состояния ДВУМЯ значениями.
Почему же не получается, "other" это ведь тоже истинное значение.
Smitis wrote:А что делать, если ВДРУГ понадобится введение чекбоксов с состоянием больше чем три?
Такого не может быть никогда. Как по мне, то единственное разумное их применение - отображение неопределённости значения. Например, перед выполнением операции в этом случае фар должен спрашивать пользователя.
К сожалению в фаре чекбоксами с третьим состоянием злоупотребляют (ну не должен пользователь лезть в документацию чтобы понять действие чекбокса!)
Smitis wrote:И, вообще, зачем придумывать лишние сущности? Тем более, что уже давно есть farapi с чекбоксами 0,1,2...
Чекбокс с двумя состояниями и чекбокс с тремя состояниями должны возвращать значения одного типа.
Smitis wrote:А то что отображается в редакторе конфигураций... Можно отображать, например, нефиг/нафиг/пофиг. Или цифрами племени Майя. К внутреннему представлению это никакого отношения не имеет.
К внутреннему не имеет. А к сабжевой функции имеет прямое отношение: должно быть одинаково.
User avatar
Smitis
Posts: 1709
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 23 times
Been thanked: 55 times

Re: Far.Cfg_Get

Post by Smitis »

John Doe wrote:Чекбокс с двумя состояниями и чекбокс с тремя состояниями должны возвращать значения одного типа.
Полность согласен! Сейчас в диалоге возвращются number (0,1 и 0,1,2).
Непонятно, почему для GetConfig должен возвращать по-другому?
Почему же не получается, "other" это ведь тоже истинное значение.
Но это другой тип данных (при том что "должны возвращать значения одного типа").
Такого не может быть никогда
"Никогда не говори никогда" (C)
Сегодня не нужно, а завтра может понадобиться. Всегда надо предусматривать возможность дальнейшего развития (расширения функционала).
К внутреннему не имеет. А к сабжевой функции имеет прямое отношение: должно быть одинаково.
Ради бога - результат функции можно ОТОБРАЖАТЬ так же, как в конфигурации. Или даже с учётом языка (вместо "other" выводить "другой"). Но зачем менять внутренее представление?
И, кстати, а где в конфигурации присутствует слово "other"?
Разум когда-нибудь победит.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Re: Far.Cfg_Get

Post by John Doe »

Smitis wrote:Сейчас в диалоге возвращются number (0,1 и 0,1,2).
Непонятно, почему для GetConfig должен возвращать по-другому?
Потому что это не АПИ, а макрофункция.
А в винапи для 0 и 1 есть константы, вы же видели Энциклопедию?
Smitis wrote:Но это другой тип данных (при том что "должны возвращать значения одного типа").
Имелось ввиду, что если это выглядит одинаково ([ ] или [x]), то и значения должны возвращаться одинаковые, независимо от типа переключателя.
Значение [?] при этом другого типа, да.
Smitis wrote:Сегодня не нужно, а завтра может понадобиться.
Чекбоксы с третьим значением надо в фаре извести, а не увеличивать их функциональность. Имхо.
Smitis wrote:Ради бога - результат функции можно ОТОБРАЖАТЬ так же, как в конфигурации [...] Но зачем менять внутренее представление?
Это макрофункция. Информацию о параметрах и значениях пользователь получает из справки, и из самого редактора конфигурации.
Поэтому отображаемые значения должны совпадать с фактическими.
Smitis wrote:И, кстати, а где в конфигурации присутствует слово "other"?
Всё видно в редакторе конфигурации (отфильтруйте по "3-state").
Например Editor.ShowWhiteSpace
Post Reply

Return to “Обсуждение макросов”