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

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

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

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

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

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

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

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

На днях копался в потрохах файлов 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 очень даже ничего.