OberonCore

Люди, работающие с Black Box. А вам не кажется, что FrameWork BB, весьма и весьма недоработан. Причем в таком колличестве, что создать что то стоящее, используя только его не представляется возможным.

Что, может дать нам этот FrameWork?
1. Возможность разрабатывать кроссплатформенные приложения?
Так не думаю. Элементарно вывести BMP файл в View приходится через функции WinApi, которых в Linux-е нет. А уж про то, что бы изменить стиль PushButton на BS_FLAT и речи быть не может без WinApi.
И обидно что в в модуле WinApi, отсутствуют напрочь многие константы, в том числе и BS_FLAT. Хотя это легко исправить.

2. Компоненты для создания GUI?
Их мало, и они ужасно выглядят. И что бы их доработать, не копаясь в исходниках BB нужно прибегать к WinApi.
3. Инструменты для разработки своих отображений(View)?
Опять же скудно. Я лично не видел ни одного хорошо отрисованного отображения(View) кнопки, списка ,таблицы.

Посмотрел тут на днях библиотеку Mt(для работы с окнами и т.д.). В процедуре MDIOff(убрать главное окно BB):
MoveWindow(....,10000,10000,....);
ИМХО, шаманство все это. Получается, все равно что с бубном вокруг Black Box прыгаешь, что бы вызвать духов и они убрали главное окно.
Легче, в таком случае отказаться от самого FrameWork-а и линковать свой Exe файл с ядром BB. Типа DevLinker.Link Prog:= National Kernel$+ Prog

Однако при всем при том, лично я от Black Box в восторге, но не как в качестве FrameWork-а, а в качестве удобного редактора и компилятора языка Oberon-2. Ибо Oberon-2 это Язык, с большой буквы.

Скажем так - в нем многого не хватает. Сам Framework как фундамент продуман очень хорошо - надо наращивать.

То, что есть во фреймворке, то кроссплатформенно. А то, чего в нем пока нет - извините, каким напишете, таким и будет. Будете все время вызвать WinApi - не будет кроссплатформенности, сделаете свое отображение как положено (с открытым абстрактным типом и инсталлируемыми фабриками конкретных) - будет вам и кроссплатформенность.

Да, шаманство. Есть параметр /NOAPPWINDOW, но у него свои нюансы...
Ну так кто виноват, что шаманство? Мы, авторы Mt, виноваты, потому что нужно было срочно выполнять проект. Oberon Microsystems обеспечила нормальный способ изменения стиля GUI - делаются аналоги трех модулей: HostPorts, HostWindows, HostCFrames, которые инсталлируют свои фабрики в Ports, Windows и CFrames. Остальная среда даже не заметит подмены - можно работать хоть с MDI, хоть с SDI, хоть на OpenGL уйти.

Framework прекрасный, расширений мало пока...

Наращивать? На данный момент я лично не вижу хорошего способа грамотно нарастить FrameWork BB. Возьмем к примеру ToolBar(Наверное уже все его скачали с сайта zinn...). Почему ToolBar? Потому, что современные прикладные программы должны иметь ToolBar-а, за исключением некоторых рисованных форм(WinAmp и т.д)

Так вот, ToolBar прикручеваеммый к BB не использует отображения, ибо через создание нового View такое сделать, ИМХО, нереально.
И если приглядется к внутренностям этого ToolBar модуля, то можно увидеть что там применяется жуткое колдовствос вызовами WinApi, ужас. (правда есть чему поучится)

Это по вашему наращивание?.
С таким же успехом можно взять Handle окна MS Word-a, и прикрутить к нему чего нибудь. А потом назвать это расширением MS Word-a. А его самого модульной системой.



Опять же. Кросплатформенное View придется делать с помощью Frame.DrawFill, Frame.DrawLine. Сделать, что либо стоящее с помощью такого рисования, архи сложно.
А если делать View, в котором используется CreateWindowEx CreateMenu, CreateToolBarEx - накроется вся кросплатформенность.
Иначе на стороне другой системы, например Linux придется искать их аналоги. И соответственно все переписывать, ибо на Linux окна строятся иначе.
В итоге для создания собственной кроссплатформенной библиотеки хотя бы для двух систем, уйдет мноооооооого времени.



Вот скажу пару слов на счет нормального изменения модулей:

На днях копался в потрохах файлов Host. Делал плоские PushButtons и что бы их Caption выводился по центру.
Потом сделал возможность открытия формы изменяемого размера, а не в виде ToolBox.
И наконец захотел сделать SDI приложением.
Суть была в том что бы добавить в модуль StdCmd процедуру OpenAsSDI, на основе OpenAsAuxDialog (Там в этой процедуре окно вызывается с некоторыми параметрами (flags: SET). В них сокрыт стиль с которым оно будет отображаться).

Так вот в своей процедуре OpenAsSDI вызов окна я хотел сделать с параметром WS_MAXIMIZE={24} и без параметра WS_SYSMENU={19}, что бы оно открылось наполную внутри BB и с него убрались системные кнопки.
Облом.
Копания в недрах модулей Host , Std и т.д ничего не дали.
Во всех найденных мной процедурах вызовов окон такие жуткие заклинания с параметрами(flags: SET) окон. Они по сто раз изменяются в каждой из процедур.
Black Box оправдывает свое название. Заглянешь в него и увидишь темноту, даже бездну, ибо комментариев в исходниках Host практически нет. (Догадайся сам)

Просто хотелось бы использовать BB по назначению. Т. е. создавать свои красивые(в стиле XP) отображения без WinApi: кнопки, списки и т.д. Но пока BB устроен так, что это проблематично.
Ко всему этому еще следует добавить, "класную" документацию по BB: "отображения отображают" и всё в таком духе. Без консультанта по такой документации, что либо понять проблематично.

Однако повторюсь, что если не пользовать FrameWork, а просто использовать WinApi и линковать свои exe, то BB очень даже ничего.

Во-первых, Host - это не Framework! Это вынесенная отдельно сбоку реализация. Она писалась уже приличное время назад, на доработку графики у создателей времени, видимо, не нашлось до сих пор - у них иная специфика деятельности. Опять, же править его не только не нужно, но и нельзя. Нужно просто писать свои реализации Ports и Windows (чем мы сейчас и занимаемся). Подключить их к среде и перенаправить всю работу с графикой на них можно даже без перекомпиляции, не говоря уже о переписывании остальных модулей - достаточно вызвать Windows.SetDirectory(ваша_фабрика_типов). Будут и тулбары, и что душе угодно...


Во-первых, кто мешает сделать расширенные кадры? Которые переносить на каждую платформу без переписывания клиентского кода? Во-вторых, кадры можно определять даже для конкретно взятого отображения - оно само решает, какой кадр с какими дополнительными возможностями использовать, через GetNewFrame.


Посмотрите на сайте Зинна подсистему Ctls - там есть графичесие плоские кнопки. А Host вообще трогать не надо - все можно сделать новыми модулями.
Выделите список подсистемы Host - вот я вам для удобства его даже дам
HostBitmaps
HostCFrames
HostClipboard
HostCmds
HostDialog
HostFiles
HostFonts
HostMail
HostMechanisms
HostMenus
HostPackedFiles
HostPictures
HostPorts
HostPrinters
HostRegistry
HostTabFrames
HostTextConv
HostWindows
и нажмите Info->Dependencies.
Вы увидите, что Host вообще не импортируется ничем кроме трех модулей из Forms. Ни один модуль Framework (подсистемы System) о существовании Host просто не подозревает. Как? ООП, батенька + модульность. Вы сами признавались, что писали ранее в процедурном стиле. Видимо, не допонимаете чего-то.
Спрашивайте - всегда поможем, но опрометчиво доказывать "не верь глазам своим" не надо

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

Эт верно. Много чего не понимаю в BB.

До BB в основном работал в Delphi (пиратская копия) и для работы, и для хобби. В нем пользовал VCL. Свои компоненты не строил и мне этого хватало.

Но недавно пришло осознание, того что пользовать ворованный софт, коим у меня был Delphi, Windows, офис и т.д., не есть хорошо. От всего ворованного я отказался, в том числе и Delphi. Купил лицензионный Windows XP и ASPLinux 11.

Потом я решил найти, замену Delphi для домашнего хобби. Пускай без VCL, но что бы было легко освоить и удобно программировать(удобная IDE чтоб была).
Перерыв кучу компиляторов в области Pascal языков, мой выбор остановился сначала на Free Pascal. Достоинства: частичная совместимость с Delphi, много библиотек, кроссплатформенность, быстроразвивающееся сообщество.
И в добавок глюки, глюки, глюки....И ни одной нормальной, не глючной графической оболочки к компилятору.

Опять начал искать. Уже хотел попробовать перейти на C++, когда под руку подвернулся Black Box. Изящный синтаксис языка, МОДУЛЬНОСТЬ, сборщик мусора и много чего еще. Единственный недостаток, трудность понимания. Оснобенно в области компонентостроения, и FRAMEWORK.
Что там чем и как управляет, до сих пор ни как разобраться не могу. Поэтому бросил шаманство с FrameWork и решил писать свои компоненты которые будут вызывать WinApi, строить GUI и т.д. Однако пока никак не получается построить нормальный каркас GUI приложения.
Никак не могу въехать как организовать CALLBACK. Что бы компоненты получали сообщения и обрабатывали их. Типа как в Delphi: OnMouseDown() и т.д.
Вот и приходится здесь Вас донимать вопросами. И шаманить с BB. Тыкаться так сказать, ибо хэлп не помогает.

Не хватает процедурных переменных связанных с объектами? Так их можно самому сделать:


VAR OnMouseDown: Delegate;

Может быть в таком случае лучше посмотреть на XDS?
После Delphi должна показаться более привычной, чем BlackBox.

Я подумываю перетащить на XDS Oberon-2 проект написанный на FreePascal 2.02 (и Delphi 5). Написан на WinAPI, 9400 строк (на текущий день). Используются четыре класса (TList, TStringList, TIniFiles и TException). Для первых двух написал замену - это основное.
Причина переноса - FreePascal генерирует код, в два раз больший, чем Delphi (350 кб против 190 кб). И немного глюков в FP (некритичных, но все же...).
Я слышал, что XDS тщательно проработан и вылизан. А это основное требование с моей стороны.
Не знаю, стоит ли овчинка выделки?

А можно немного пояснений к коду с примером для изучающий BB?
(Мне вот нужно отловить событие изменения ячейки в CtlExcel9.Worksheet)

Вячеслав, не Вы где-то в соседней ветке спрашивали уже про Excel? Не могу найти ту тему... В принципе, всю информацию по Office можно найти http://msdn.microsoft.com/office/ - посмотрите. Есть еще книжка неплохая: Трепалин, Елманова, Тенцер "Программирование COM в Delphi", изд-ва Питер, серии "Мастер". Там про офис раздел был. К сожалению, у меня ее сейчас нет под руками, посмотреть ничего не могу.

XDS-Native пробовал, и XDS-C пробовал.

XDS-Native неплох. Однако, толька не пынайте, , хелп по нему англиский, и сообщества рускоговорящего нет, покрайней мере не нашел.

А ещё мне вспоминается долгое шаманство с SYSTEM.ADR(...) . Я никак не мог въехать почему компилятор ругается, что типы не соответствуют. Пока в справке по XDS не нашел, что SYSTEM.ADR, не возвращает указатель, а INTEGER. И что вместо него нужно использовать O2ADR..... Зла не хватает.

С XDS-C вообще не долго парился. Сгенерированный им Си-шный код программы Hello World не скомпилировался DEV-C++(Mingw), даже с родными XDS-C библиотеками.

На данный момент BB мне больше нравится. Особенно когда я начал въезжать в суть компонентов.

Именно! Сам неоднократно сталкивался с этим. Утилиты конвертации работают "в лоб", глупо и неинтелектуально. Т.е. программист-кодер должен из своей головы постоянно доставать недостающие знания и пытаться заставить работать.

Занимаясь автоматизацией программирования запускал некоторые конвекторы:

• С языка Oberon-2 to C
  
• Паскаль в Oberone.
  
• Турбо Паскаль в Компонентный Паскаль.

Программы переводят код, но это "полуфабрикат" и работает на некотором множестве конструкций и операторов.

Можно было бы проверить входной код, проанализировать проект: исходные файлы, заголовочные файлы, библиотеки. Доступность к этим файлам и внутренним функциям. Этого не делается!

Недавно скачал и собирал кроссплатформенную библиотеку wxWidgets-2.6.3.
Собирал по инструкции:
a) C++ Builder v5.0 - НЕТ
б) C++ Express 2005 - НЕТ
в) MinGW - ДА

Значит "слоновая болезнь" - изначальная недоработка IDE инструмента от гигантов софта. Некогда им подумать о нас с вами, кодеров-программистах, и в спешке кидают нам плохо проработанный способ строить приложения.

Поэтому BlackBox - удивительное исключение. Быстрый практический результат от идеи до реально работающего приложения!

SYSTEM.ADR и должен возвращать INTEGER, это написано в "The Programming Language Oberon(-2)".
А что такое O2ADR?

Может и ошибся.

Я тогда В XDS с помощью SYSTEM.ADR в функции WinApi указатель на переменную пытался отослать. Безрезультатно.

И насчет "O2ADR". Сейчас точно не помню, то ли "M2ADR", то ли "O2ADR". В справке по Oberon-2 XDS написано, что за место SYSTEM.ADR, надо использовать SYSTEM.O2ADR.
Я так понял это всё из-за того что XDS компилятор и modula-2 и oberon-2 в одном флаконе.

Спасибо за ответ, Илья. Но меня не Excel интересует Мне не понятно как работать с процедурой

из модуля CtlExcel9. Вся моя проблема заключается в том, что я не могу разобраться как отловить событие изменения значения в ячейке таблицы, чтобы вызвать соответствующий обработчик. А больше мне от Excel ничего не надо

Про SYSTEM.ADR, INTEGER и SYSTEM.O2ADR. Наверное дело в разрядности платформы. В Обероне-2 ведь INTEGER - 16 битный. То есть на 32-разрядной платформе SYSTEM.ADR должен возвращять обероновский LONGINT. Чтобы не путаться между INTEGER и LONGINT, ИксДэЭсовцы наверное и ввели generic тип SYSTEM.O2ADR.

Для начинающих/изучающих если тот код не понятен, то и нечего его использовать. Необходимости, по крайней мере, в нём нет...

Сказывается тяжёлое наследие Си.

Адрес - это целое число, в то время как указатель - это особый тип данных.

Так, итить. В WinApi данные через указатели передаются.

А в справке по Oberon-2 написано, что SYSTEM.ADR возвращает УКАЗАТЕЛЬ.

Или я не прав, и мне стоит идти учится, начиная с математики за 7 класс ?

Возможно, неточность перевода. Или имелось в виду "целое число, которое имеет смысл указателя"...