OberonCore

Кнопка как коммандер - для конечного приложения

Коммандеры - это хорошо, все мы это знаем.

Это хорошо даже и для обычных пользователей, хотя обычные пользователи не всегда об этом знают

Только вот "совсем конечного..." пользователя... не всегда хочется пугать видом команды после коммандера. Хочется, чтоб была просто клюкабельная пимпочка, а после - текст для обработки.

Вуаля. Делаем где-нибудь процедуру:



Далее мы можем вставлять вместо коммандера кнопку, в Link которой перед основным действием вписываем GetButtonPar.
Закрываем командную строчку пустой кнопкой (ну или другой командной, всё как у обычных коммандеров).

(Конечно, для компиляции никто кнопку использовать не будет; это так, сляпано для примера...)

Командную строчку, кстати, можно разбавлять пояснениями с помощью обычного Caption, т.к. при разборе строчки сканер (и всякие модули In) будет эти вьюшки игнорировать.

А чем ссылкоподобные команды не нравятся?
<WorkReportCfg.Do;StdCmds.OpenToolDialog('Work\Rsrc\ReportCfg','ReportCfg')>Конфигурация отчётов в БД<>

Наконец-то хорошая тема. "Текст как интерфейс".
А как тут доступ к текущему тексту с вводимыми данными?
Штука в том, что "активный" текст гораздо удобней обычной формы ввода в плане гибкости организации данных.
---
Кстати, заодно пример бы как в текст вставить слот для ввода числа, например.

Всю эту тему ("Текст как интерфейс") хорошо бы тут проработать.
(И, возможно, ветку переименовать соответственно?)

Аналогично, через StdLinks.par, но
- нужно искать закрывающий "линк"
- придумать чем ограничивать параметры после него. В примере выше ограничивается таким же контролом.Поддерживаю.

Долго думал, и додумался:

В модуль типа In
(сам In я предпочитаю не трогать по той же причине, по какой его не трогали авторы ББ; у меня для этих целей есть стандартная замена i21sysIn)
добавить средство типа "открыть входной поток"
и оно делает потоком ввода выделенный фрагмент текста в окне с фокусом (точнее, его копию).

А потом программа (которая вызывается из меню или командиром в другом документе) не открывает поток, а только, если надо, читает с начала (Restart).
Все старые рутины (т.е. уже налаженные программы с командирами и данными, организованными по старой схеме) сохраняются и работают.

Плюс явно экспортирован сканер, чтобы полноценно сканить поток ввода.



Прилагаю текущий вариант i21sysIn (он во всех комплектах на предполагаемом диске, их я попозже отдельно выложу на сайте, пусть бета-тестеры трапы поищут, чтобы сразу исправить).

А для вывода пришел пока к ... выводу, что пускай в Лог печатает. Взять оттуда не проблема, а потенциальная путаница в противном случае может быть большая (если не видно, куда идет выдача, то легко запортить че-нить).

Про это тоже долго думал -- если сразу с маленькой буквы, то не надо потом объяснять, почему важно соглашений придерживаться. Это Done торчит всюду.

Совсем убрать Done -- примеры в книжке Виталия Валерьевича не будут работать

О каком диске идет речь?

Приложение к книге:

viewtopic.php?f=4&t=1970

Где можно об этом почитать?

В вывешенном исходнике.

In -- не является частью Блэкбокса.

Это я знаю, что не является. Мне интересно почитать, по каким-таким причинам разработчики косо на него смотрели.

Почему косо? Наверное, чтобы проще было примеры Вирта на Обероне запустить.

В исходнике есть комментарий.

... тут нюансы, все сразу не помню, но один вот:

Когда две разные команды должны брать данные из входного потока -- то плохо, когда они обе пытаются его открывать.
Но если каждая сделана так, что просто его читает "с текущей позиции", то данные для этих двух последовательных команд тоже просто две сконкатенированные последовательности.
Удобней именно так (это вывод из "долго думал", причем с реальным примером из жизни).

В любом случае так сделанную команду можно обеспечить данными, приставив впереди Open:

(!)"i21sysIn.Open;Модуль.Команда(параметры)" поток ввода ~

В общем, такое параллельное складывание команд и их потоков данных.

Открытая опция (ее, как представляется, нужно будет реализовать) -- добавить возможность делать интерактивную конкатенацию потоков данных, т.е. наряду с Open добавить Append, когда выделенный фрагмент текста прицепляется к уже "туда" зааттаченному.
Но это добавление к модулю чисто аддитивное, всё уже существующее не будет затронуто.

И последний сейчас пунктик: Restart, строго оговоря, избыточен: раз виден сканер, -- а именно он работает, когда вызываются команды чтения Int, Real и т.д., -- то можно запомнить его позицию и, когда надо, туда его снова поставить.
Но на практике (особенно в учебном контексте) это достаточно громоздко, чтобы оправдать спецфасадик.

Для заметки: в книге Рейзера "Система Оберон..." (http://oberoncore.ru/library/reiser_the ... ers_manual), раздел 1.2 The Oberon user interface, стр. 4 и стр. 7 --- картинки, где сравниваются одномерная ком. строка MS-DOS и текст как ком. строка в системе Оберон.

Должно быть полезно в образовательных целях.

P.S. Тему приклеил, чтобы опять не искать.

У Раскина в "Интерфейс ..." есть моменты, касательно текста как интерфейса. Причем они почти в таком же виде как описываются у него, реализованы в ББ (например, редактируемое меню, коммандер)

Спасибо.

"Content as interface".

Вот для полноты сводка правил (где-то, наверное, есть и по-русски):

http://nitpicker.pbworks.com/w/page/124 ... 0Interface

Мне видится разумным следующий вариант. Пользователь пишет текст команды, выделяет его, щёлкает с какой-нибудь зажатой функциональной клавишей и текст превращается в нажимаемую ссылку-текст. Её редактирование - это уже редактирование названия html-подобной ссылки. В любой момент можно снова превратить ссылку в текст. Из выгод: сохранение приличного вида (Открыть, Закрыть, Сохранить как, Показать результат) на языке целевого назначения, но при этом сохраняется возможность менять содержимое команд и создавать новые в любом месте.

SomeModule.Open => Открыть базу данных