SMS

Dear Alexander,

20 Jan 04 03:38, Alexander Derazhne wrote to Serge Bryxin:

SB>> для состояния формы ввода кнопки Up/Dn/Ok будут отрабатываться как SB>> переход на то же самое состояние с функциями выхода из состояния, SB>> меняющими содержимое соответствующих переменных.

AD> по опыту - уже двухуровневое меню в двухстрочной ЖКИ-амбразуре AD> _невероятно_ неудобно. Добраться до нужного места, установить нужные AD> IP адреса и корректно выйти обратно... жалко мне пользователей

1) В предыдущем резговоре не было ни одной ссылки на уровневость меню. Структура графа вообще такого понятия не предполагает. Т.е. все в руках дизайнера интерфейса. 2) У тебя есть сотовый телефон? Или так: у тебя был сотовый телефон несколько лет назад, когда они почти все обладали однострочными фактически меню? Было _неверотно_ неудобно? Я как-то переживал это дело... :-) 3) А ты как предлагаешь реализовать ввод IP адреса? Отдельными кнопками специально для ввода этого адреса? :-)

AD> Далее. Описываемый тобой механизм сводится к спин-боксам двух типов - AD> с непосредственным числовым значением при установленных ограничениях AD> (считаем только от 0 до 59) и с косвенной выборкой (выбор перебором AD> одной из мнемоник).

Механизм к этому не сводится. К этому сводился приведенный частный пример использования механизма. Изрядная кастрированность интерфейса в данном случае обусловлена не предложенной структурой данных, а малым количеством кнопок. Hо я сразу предупредил, что она не годится (или годится с серьезными ограничениями) для больших клавиатур. Для большой клавиатуры я бы предложил event-driven интерфейс.

Да и в конце концов исходный вопрос звучал как удобная организация именно меню. Здесь формы появились только в результате приведения идеи к наиболее общему случаю. А для _только_ меню у меня в одном проекте было реализовано то же самое, но проще:

menu1: .dw menu11,empty ; Ok - вход в cледующий уровень, ничего не делать .dw 0 ; Esc - выход из меню .dw menu2 ; Up - следующий пункт .dw menu3 ; Dn - предыдущий пункт (закольцовано) .db "Меню 1",0 ; текст menu11: .dw 0,SetTime ; выполнить SetTime и покинуть меню .dw menu1 .dw menu12 .dw menu13 .db "Меню 1.1",0

AD> Всё значительно усложнится, если потребуется верификация AD> [совместимости] вводимых значений на лету и/или появятся связи между AD> значениями

Да.

AD> Подобные проверки, нерегулярности и взаимозависимости довольно AD> тяжело вылавливаются и без машины состояний, тут вопрос совсем не в AD> механизме описания.

Да. Hо я приводил механизм описания.

Dear Dima,

20 Jan 04 12:29, Dima Orlov wrote to Serge Bryxin:

DO> При разной длине и допустимом диапазоне значений, особенно если эти данные DO> зависят от других у нас как-то очень громоздко получилось при похожей DO> исходной идее.

Да. Я охотно верю, что есть задачи (интерфейсы), в которых эта идея для ввода данных плохо подходит.

Sincerely yours, Old Greaser.

Hello, Serge! You wrote to Alexander Derazhne on Wed, 21 Jan 2004 12:16:00 +0300:

AD>> по опыту - уже двухуровневое меню в двухстрочной ЖКИ-амбразуре AD>> _невероятно_ неудобно. Добраться до нужного места, установить AD>> нужные AD>> IP адреса и корректно выйти обратно... жалко мне пользователей

SB> 1) В предыдущем резговоре не было ни одной ссылки на уровневость SB> меню. SB> Структура графа вообще такого понятия не предполагает. Т.е. все в SB> руках дизайнера интерфейса.

Если ты реализуешь структуру меню в виде графа общего вида, то пользователю придётся ходить на курсы по этой железяке :-)).

SB> 2) У тебя есть сотовый телефон? Или так: у тебя был сотовый телефон SB> несколько лет назад, когда они почти все обладали однострочными SB> фактически меню? Было _неверотно_ неудобно? Я как-то переживал это SB> дело... :-)

Не знаю, мобилки у меня нет до сих пор и ничего, обхожусь как-то.

SB> 3) А ты как предлагаешь реализовать ввод IP адреса? Отдельными SB> кнопками специально для ввода этого адреса? :-)

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

AD>> Всё значительно усложнится, если потребуется верификация AD>> [совместимости] вводимых значений на лету и/или появятся связи AD>> между значениями

SB> Да.

AD>> Подобные проверки, нерегулярности и взаимозависимости довольно AD>> тяжело вылавливаются и без машины состояний, тут вопрос совсем не в AD>> механизме описания.

SB> Да. Hо я приводил механизм описания.

Тогда уже всё равно как описывать - функции верификации внесут куда больше накладных расходов.

Alexander,Derazhne@adic,kiev,ua (replace commas with dots) Alexander Derazhne

Э! Когда printf это PRINTF - то он у тебя есть! А если его нет - то делай как бог на душу положит! Я вообще сторонник форматов типа $1..., $2... - при интернализации помогает.