Как /400: другой способ отображения графики?
Я знаю о существовании файлов DDS, которые позволяют программировать отображаемую графику на /400, но есть ли другой способ?
В частности, я хочу манипулировать терминальным буфером напрямую, чтобы иметь возможность отображать что-то еще, кроме текста. Например, терминал выглядит так: 
Скажем, в памяти будет двухмерный массив символов: text[20][80] для текстового меню и ниже, будет массив пиксельных буферов размером [200][800].
Есть ли способ получить доступ к любому из этих массивов напрямую? Я хотел бы иметь возможность создавать отображаемое меню полностью на C без необходимости отображать файл, а также отображать другие виды графики (изображения) непосредственно в пиксельном буфере.
3 ответа
Есть ли способ получить доступ к любому из этих массивов напрямую?
Это достаточно просто, хотя "файл отображения", который не имеет отформатированных полей, все еще будет необходим. "Файл" - это соединение между программой и физическим устройством (или эмулятором). Вы можете определить одну большую область, которая содержит любой "текст", который вы хотите, чтобы ваша программа поместила в него. Это может даже включать атрибуты поля отображения, которые разграничивают области ввода.
Для большей части контроля подходит ключевое слово DDS USRDFN. Но для простых вещей, таких как списки пунктов меню, почти любое большое текстовое поле может быть выведено в.
Вывести простой текст легко. Для таких подробностей, как форматирование USRDFN, необходимо детальное понимание протокола 5250.
Одним из альтернативных вариантов может быть использование API-интерфейса диспетчера пользовательского интерфейса (UIM) для обновления "текстовой области" панели (:TEXT) через ее прикладную программу USREXIT=. UIM обрабатывает все, что касается любого определения "отображаемого файла" и фактического ввода-вывода. UIM может рассматриваться как HTML-интерфейс для 5250 и использует очень похожий язык разметки для определения панелей.
Другой альтернативой являются API-интерфейсы Dynamic Screen Manager (DSM). Они дают намного более точное управление, чем методы UIM или DDS (хотя DDS USRDFN подходит очень близко). Но, как и в USRDFN, для реального управления устройством потребуется знание протокола 5250.
... а также отображать другие виды графики (изображений) непосредственно в пиксельном буфере.
Для 5250 нет ни "пиксельного буфера", ни даже "пикселей". Это протокол на основе символов, такой как telnet. Если вы работаете с изображениями или "пикселями", вам нужны интерфейсы браузера, или, возможно, Java и NAWT, или X-windows и т. Д.
Теперь, учитывая, что с TCP/IP и сокетами вы можете делать практически все, что можете программировать. Все, что вы можете выяснить, как это сделать, включая загрузку / установку сторонних библиотек кода, вы можете сделать - в рамках сетевых ограничений, окружающих ваш сервер. Но на самом деле это сервер, поэтому приложения с графическим интерфейсом обычно не должны работать на нем. Это так же, как для почти всех типов серверов. Кодируйте графический интерфейс на клиентской системе, а не на сервере. Но вы можете сделать это, если вы действительно хотите.
Я не уверен, почему вы хотите это сделать...
В настоящее время было бы гораздо проще просто сгенерировать вывод в виде HTML и обработать его через встроенный веб-сервер Apache.
Но если вы действительно хотите делать графику через 5250, это можно сделать... теоретически, по крайней мере. За 20 с лишним лет на платформе я никогда этого не видел.
Но еще в далеком (1994?) Году IBM добавила поддержку диспетчера графического отображения данных (GDDM) и API презентационной графики в OS/400. "GDDM - это средство отображения, печати или печати рисунков. Процедуры Presentation Graphics - это средство отображения, печати или печати бизнес-диаграмм".
Поддержка все еще в ОС. Однако поддержка на стороне клиента НЕ доступна в IBM i Access for Windows или в недавно выпущенном клиенте, IBM Access Client Solutions (ACS). Похоже, что автономный продукт IBM Personal Communications может поддерживать GDDM.
Для полного контроля над символьным буфером посмотрите API-интерфейсы Dynamic Screen Manager (DSM). API DSM - это "набор экранных интерфейсов ввода-вывода, которые обеспечивают динамический способ создания и управления экранами для языков высокого уровня Integrated Language Environment® (ILE). Поскольку интерфейсы DSM являются привязываемыми, они доступны для программ ILE только."
Есть способ сделать это в ILE C/C++. Это было очень весело исследовать, так как я сам не пробовал.
Единственная документация по нему (стр. 183+), которую я смог найти, - из 5.1, но вы можете сделать перекрестную ссылку на функции, используемые в этом руководстве по 7.3 (возможно, на странице vii/7), чтобы увидеть, используются ли они по-прежнему.
Надеюсь, это помогло!