- Vote on answer
- posted
20 years ago
SMS
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
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о я приводил механизм описания.
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
Dear Dima,
20 Jan 04 12:29, Dima Orlov wrote to Serge Bryxin:DO> При разной длине и допустимом диапазоне значений, особенно если эти данные DO> зависят от других у нас как-то очень громоздко получилось при похожей DO> исходной идее.
Да. Я охотно верю, что есть задачи (интерфейсы), в которых эта идея для ввода данных плохо подходит.
Sincerely yours, Old Greaser.
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
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
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
Э! Когда printf это PRINTF - то он у тебя есть! А если его нет - то делай как бог на душу положит! Я вообще сторонник форматов типа $1..., $2... - при интернализации помогает.
- Vote on answer
- posted
20 years ago