Latest post of the previous page:
SmitisМожет быть вы обрисуете сценарий, в котором требуется обрабатывать неудачу?
Latest post of the previous page:
SmitisНа предыдущей странице было.John Doe wrote:Smitis
Может быть вы обрисуете сценарий, в котором требуется обрабатывать неудачу?
где создаются?Smitis wrote:и все отсутствующие параметры создаются при запуске ФАРа.
и в чём проблема. параметры фару нужны для работы, куда они могут деться?Smitis wrote:В config.cpp
В процессе разработки Far Manager настройки (имена ключей и имена значений) могут меняться, добавляться и удаляться, поэтому Вы используете функцию на свой страх и риск. Поддержка функционала (имена ключей и имена значений) со стороны разработчиков не гарантирована.
При таком подходе как раз и нужна проверка существования параметра. Первоначальный вариантВ процессе разработки Far Manager настройки (имена ключей и имена значений) могут меняться, добавляться и удаляться, поэтому Вы используете функцию на свой страх и риск. Поддержка функционала (имена ключей и имена значений) со стороны разработчиков не гарантирована.
ok, val, tp = Far.GetConfig (key, name)
это как раз и предусматривал. А сейчас получается половинчатое решение - проверить функцией наличие параметра нельзя, зато есть малонужное значение tp, во-первых, тип параметра, так же, как и значение keyname, уже известны заранее, во-вторых, тип возвращаемого значения и так можно проверить через type.значения разного типа выглядят криво. Может проще оставить "как есть" 0,1,2? Тем более уже есть DM_GETCHECK и DM_SETCHECK именно так и работающие.3-state -> 0,1,2 преобразуются соответственно в false,true,"other"
Проверка есть, в случае отсутствия исполнение останавливается с ошибкой.При таком подходе как раз и нужна проверка существования параметра.
Зато сейчас значения можно использовать в логических выражениях, да и в целом они соответствует тому, что мы видим в редакторе конфигурации.значения разного типа выглядят криво. Может проще оставить "как есть" 0,1,2?
зачем?Smitis wrote:При таком подходе как раз и нужна проверка существования параметра.
Как это нельзя, pcall пока ещё никто не отменял.Smitis wrote:Первоначальный вариантok, val, tp = Far.GetConfig (key, name)
это как раз и предусматривал. А сейчас получается половинчатое решение - проверить функцией наличие параметра нельзя
Я понимаю, что ОЧЕНЬ хочется чекбокс представлять как логическое значение. Сам с этим столкнулся в DialogClass. Но не получается представить ТРИ состояния ДВУМЯ значениями. У меня в DialogClass в результате этих терзаний появились два вида методов, одни работают с числовыми значениями, другие с логическими, причём последние мне категорически не нравятся, так как допускают неопределённость и я думал их убрать. Всё равно всё завязано на api где таких "логических" проблем нет.John Doe wrote:Зато сейчас значения можно использовать в логических выражениях, да и в целом они соответствует тому, что мы видим в редакторе конфигурации.
Почему же не получается, "other" это ведь тоже истинное значение.Smitis wrote:Я понимаю, что ОЧЕНЬ хочется чекбокс представлять как логическое значение.
Но не получается представить ТРИ состояния ДВУМЯ значениями.
Такого не может быть никогда. Как по мне, то единственное разумное их применение - отображение неопределённости значения. Например, перед выполнением операции в этом случае фар должен спрашивать пользователя.Smitis wrote:А что делать, если ВДРУГ понадобится введение чекбоксов с состоянием больше чем три?
Чекбокс с двумя состояниями и чекбокс с тремя состояниями должны возвращать значения одного типа.Smitis wrote:И, вообще, зачем придумывать лишние сущности? Тем более, что уже давно есть farapi с чекбоксами 0,1,2...
К внутреннему не имеет. А к сабжевой функции имеет прямое отношение: должно быть одинаково.Smitis wrote:А то что отображается в редакторе конфигураций... Можно отображать, например, нефиг/нафиг/пофиг. Или цифрами племени Майя. К внутреннему представлению это никакого отношения не имеет.
Полность согласен! Сейчас в диалоге возвращются number (0,1 и 0,1,2).John Doe wrote:Чекбокс с двумя состояниями и чекбокс с тремя состояниями должны возвращать значения одного типа.
Но это другой тип данных (при том что "должны возвращать значения одного типа").Почему же не получается, "other" это ведь тоже истинное значение.
"Никогда не говори никогда" (C)Такого не может быть никогда
Ради бога - результат функции можно ОТОБРАЖАТЬ так же, как в конфигурации. Или даже с учётом языка (вместо "other" выводить "другой"). Но зачем менять внутренее представление?К внутреннему не имеет. А к сабжевой функции имеет прямое отношение: должно быть одинаково.
Потому что это не АПИ, а макрофункция.Smitis wrote:Сейчас в диалоге возвращются number (0,1 и 0,1,2).
Непонятно, почему для GetConfig должен возвращать по-другому?
Имелось ввиду, что если это выглядит одинаково (Smitis wrote:Но это другой тип данных (при том что "должны возвращать значения одного типа").
[ ]
или [x]
), то и значения должны возвращаться одинаковые, независимо от типа переключателя.[?]
при этом другого типа, да.Чекбоксы с третьим значением надо в фаре извести, а не увеличивать их функциональность. Имхо.Smitis wrote:Сегодня не нужно, а завтра может понадобиться.
Это макрофункция. Информацию о параметрах и значениях пользователь получает из справки, и из самого редактора конфигурации.Smitis wrote:Ради бога - результат функции можно ОТОБРАЖАТЬ так же, как в конфигурации [...] Но зачем менять внутренее представление?
Всё видно в редакторе конфигурации (отфильтруйте по "3-state").Smitis wrote:И, кстати, а где в конфигурации присутствует слово "other"?