Я говорил только о сложности предоставляемого в BlackBox разработчику инструмента для создания графического интерфейса. Почему его недьзя было бы реализовать на основе DOM XML (сообщение 5901)?

Ответ на »сообщение 5904« (Сергей Кузнецов)
___________________________

Разработчики BlackBox проигнорировали принципы простоты, закладывавшиеся в Oberon.

Блэкбокс был придуман как средство разработки переносимых (Вин-Мак) графич. приложений, автоматически принимающих look-and-feel соотв. платформ. Одно это заранее закладывает некую сложность. С другой стороны, благодаря этому у ББ есть стойкое и растущее сообщество.

Разработчики BlackBox проигнорировали принципы простоты, закладывавшиеся
в Oberon.
  Обоснованим этого утверждения может быть предлагаемый программисту в Oberon инструмент для создания пользовательского графического интерфейса. Он настолько сложен, что требует создания визуальных средств, как это уже делалось в VisualBasic и Dalphi.

Ответ на »сообщение 5900« (Сергей Кузнецов)
___________________________
Это вам нужно написать в тему про Русскую ОС. Но боюсь что у Микрософта нет никаких "благих намерений" заботиться о устоявшемся рынке. Взять хотя бы Silverlight. Чем он лучше существующих решений? И т.д.

Ответ на »сообщение 5901« (Сергей Кузнецов)
___________________________
А такой подход уже давно применяется в некоторых кроссплатформенных программных продуктах.

Хотелось бы получить комментарии по вопросу, связанному с предоставляемым
  пользователю инструментом по созданию графического интерфейса.
      Насколько я понимаю в Delphi и BlackBox, графический инструмент строится на
  на основе базовых классов типа "кнопка", "форма" и пр.
      Почему не рассматривается вариант создания графического инструмента
  на базе объектов, реализующих динамическую объектную модель XML (DOM XML)
  и наследуемого HTML?
    Я реализовал этот способ на Borland Pascal 7.0 под DOS в реальном
  режиме. Получилось достаточно компактно. И на мой взгляд работать с этим
  много проще, чем с Delphi, т.к. все обозримо и без визуальной среды разработки.
  Описание интерфейса делается в HTML-файлах, а реализация скриптовых
  функций для обработчиков переносится в методы объектов (можно в объект
  документа).
  Если же ставить задачу разработки визуальной среды, то мне представляется,
  что ее реализовать проще, чем в Delphi.
      При реализации DOM XML появляется и дополнительный бонус.
  При разработке большинства программ программист имеет дело с данными.
  Весь код программы (разбросанный по разным частям) можно считать реализацией
  некоторого интерпретатора. Причем интерпретатора, построенного без учета
  всяких наработок по созданию языков. В случае же DOM XML мы имеем
  встроенную в систему реализацию хорошего языка для работы с данными.

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

      В обсуждении часто упрекают МикроСофт в том, что их усилиями задвигаются
  "на обочину" достаточно передовые идеи. Я согласен с тем, что это
  "имеет место быть", однако взглянем на деятельность МикроСофт с несколько
  иной стороны.
      Для развития отрасли в целом нужен какой-то механизм, и по-моему именно
  МикроСофт его смогла создать в рыночных условиях, сформировав
  занитересованность промышленности и потребителей.
      И, мне кажется, не "злая намеренность" МикроСофт, а несоответствие
  этой задаче ведет к отсечению многих идей и технологий - в силу отсутствия
  самостоятельной мощной материальной подпитки.

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

      Кстати, к использованию ОТ. Предприятия, опиравшиеся в своих разработках
  на использование Эльбрус, остались, а технику и инструменты им надо менять.
  И здесь (как мне кажется) использование и развитие ОТ возможно, учитывая,
  что пользоваться наработками MainStreem здесь крайне неуместно по целому
  ряду причин (перечислять не буду).

      Вообще, можно, действуя аналогично МикроСофт, попытаться создать рынок,
  но не общего назначения, а для пользователей специализирующихся в
  военнопромышленном комплексе. И паче чаяния на таком рынке ОТ была бы
  востребована.

Ответ на »сообщение 5898« (info21)
___________________________
А нельзя как-нибудь хоть одним глазком...?

Ответ на »сообщение 5896« (Alexey Veselovsky)
___________________________

Я таки дико извиняюсь, но что там с Обероном-07? Должно было выйте в конце лета. Потом в начале октября...

Не надо "дико" :-)

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

Дык что, оберонщики совсем на Руси перевелись? =) или все на компонентный паскаль перешли? Очень необходимы 2 ответа на вопросы- 1.Как в обероне заполнить массив(ниже приведен пример), 2. Пользуюсь компилятором POW!, в котором используется модификация оберона Red Chili Oberon-2 v.1.3a, в хелпе написано, что вызывать процедуры из длл либы надо так: PROCEDURE [_APICALL]. Как это можно осуществить, если кто знает, напишите, пожалуйста, с примером.