Ответ на
»сообщение 3106« (Как слышно? Приём!)
___________________________
>>>Если Вам всё просто и понятно в ББ, то нормальным людям :) непривычно.
Хе, только вот детишки 9-классники у меня уже на третьем занятии формочки с кнопочками делали без каких-либо проблем... При этом никакого ООП или событийки, и программный код совершенно чистый, не знающий ничего о прицепленном к нему ГУЕ...
Что касается Дельфы, то из-за "разврата" с ООП, мгновенно формирующейся у самоучек привычкой лабать код в обработчиках, непонятного для новичка ГУЕ-вого кода я бы к ней школьников вообще не подпускал... :-)
>Сделать бы лазейку - западёнку в ББ в виде проекта
>"сунь дельфист пальчик - там сидит зайчик".
>Или это мост от Маниловки до Санкт-Питербурга?
Да вот Вы не первый...
http://forum.oberoncore.ru/viewtopic.php?t=374 - вон сколько копий переломано...
У кого есть время и желание, пущай делают... Никаких принципиальных загвоздок там нет, за единым вопросом - ну а на фига козе баян? Вы в этой ветке на последнюю страничку зайдите - там пара студентов-новичков выссказалась. Общая мысль: "после Дельфы сильнейшая ломка стереотипов. В основном трудно поверить, ЧТО ОНО РЕАЛЬНО ТАК ПРОСТО И УДОБНО МОЖЕТ РАБОТАТЬ".
>Сходив по Вашей ссылке на форуме ББ правильный ли я сделал вывод,
>что если так приспичило создать мини-Дельфи в ББ (или мини Lazarus)
>в плане бросания кнопок, текстовых боксов, картинок и гридов(?),
>то в своём проекте реально создать панель инструментов и их бросать
>для компоновки простого GUI. (Есть соответствующие обработчики).
Так они так бросаются прекрасно... Через меню, правда. Можно поставить тулбар из коллекции Хельмута Зинна (
http://www.zinnamturm.de/) и настроить кнопки для кидания.
Можно слепить свой диалог-"палитру", повесив на него команды вставки контролов... Все же прозрачно, все делается единообразно, Блэкбокс - сам себе скриптовой язык.
>Другое дело - привязывание простейших событий Click, MouseDown
>к тексту программы. Или тут тоже есть решения?
Что вы имеете в виду?
Вообще в Блэкбоксе есть подразделение графических объектов.
Есть просто отображение Views.View - самый общий класс.
Мы пишем тип-расширение View, реализовываем в нем по минимуму процедуру Restore, которая рисует то, что нужно - и уже получаем пассивный графический объект, который можно всовывать куда угодно - на форму, в текст, всюду.
Если нужно обрабатывать сообщения, то реализуем один или несколько из методов HandleCtrlMsg, HandlePropMsg, HandleViewMsg, HandleModelMsg. Через эти обработчики отображение подключается к шинам сообщений и может обрабатывать самые разные сообщения, селектором типа WITH.
Есть, однако, и специализированные виды графических объектов (здесь, кстати, используется наследование реализации. Иделогия Framework допускает наличие нескольких базовых расширяемых конкретных типов). Controls.Control - это потомок Views.View, предназначенный для быстрого построения элементов управления. Там реализована логика автосвязывания с переменными в коде программы. Все стандартные элементы управления - кнопки, переключатели и т.п. - это потомки Control, они подключаются прямо к переменным и процедурам модулей, что очень удобно. Также контрол привязывается к процедуре-стражу (Guard), которая периодически опрашивается средой на предмет состояния контрола (активен-неактивен и т.п. - это позволяет описывать смену состояний декларативно, в одном месте, практически логическим предикатом, в то время как в Дельфе нужно следить, чтобы всюду по коду правильно переключалось Enabled и т.п.). Еше у контрола есть Notifier, который вызывается при некоторых событиях типа нажатия-отпускания кнопки мыши. Для расширенной обработки сообщений стандартная схема контролов не предназанчена, ее назначение - быстрое построение форм. Нужно более сложное поведение - нужно переопределять обработчики сообщений View.
>И частный - как с гридами? Что-то не пойму есть ли они? Или я плохо искал?
Гриды - таблицы что ль? Есть StdTables, например. А дополнительно очень многое в коллекции Зинна найдется (
http://www.zinnamturm.de/).
Ещё вопросик по той же ссылке на форуме. Вы писали
>>> кладем несколько отображений-форм (FormViews),
>>> на них накидываем графики (я кинул из Excel
Excel как поддерживается - по OLE или на манер OpenOffice?
По OLE... В той ветке Вы не на то внимание обратили. Там ниже пример разработки отображения-контейнера для графика, поддерживающего "накидывание" форматированного текста - и непосредственное редактирование - всего в пару сотен строк кода...
У меня есть набор фокусов, которые я показываю обычно новичкам.
Даже самые простые вещи дельфистов приводят обычно в замешательство. Возможность прицепить поле ввода прямо к переменной - и то, что в то же мгновение связь установится и покажется значение. Изменили экспорт переменной на "только для чтения" - и поле тут же становится недоступным для редактирования. Автоматическое отсечение ввода по типу переменной, никаких специальных усилий для этого...
Открываем редактируемую форму в рабочем режиме (Controls->Open As Tool Dialog) - и видим сразу и разметку, и рабочий вид. Подвинули в разметке кнопку - она тут же синхронно поехала в диалоге... Дельфисты на этом месте уже выпадают в осадок :-)
Далее мой любимый фокус. Открываем вертящийся кубик из примеров (Obx->New Cube). Копируем его в буфер (Edit->Select Document, Copy). Создаем новый документ и вставляем в него несколько раз этот кубик. Можно поменять размеры - кубики клонируются, масштабируются, крутятся, ну, как положено.
Далее выделяем текстовый документ целиком (Select Document), копируем - и вставляем на форму...
Дельфисты в состоянии, близком к полуобморочному, наблюдают форму, открытую сразу в двух режимах, на которую попал форматированный текстовый документ, внутри которого продолжают крутиться кубики...
Остается "добить" - прямо на форме щелкнуть по тексту - и прямо там начать его редактировать.... Все. Гоголь, последний акт, немая сцена :-)))
Ответ на
»сообщение 3109« (Сергей Перовский)
___________________________
Ответ на »сообщение 3106« (Как слышно? Приём!)
Причина одна - продуманное наследование по реализации сокращает общее количество кода и упрощает отладку. Переписать, например, Дельфовскую VCL без наследования по реализации мне представляется малоподъемным проектом даже для крупной компании, не говоря уже о сообществе энтузиастов.
Вот далось Вам это наследование...
Как будто нет других схем повторного использования.
Не нужно делать "жирные" классы, наооборот - делить ответственность между небольшими классами.
Тогда переписывается только тот маленький кусочек, который нужно заменить.
Пример - в BlackBox подсистема работы с текстами состоит из 4 модулей - TextModels, TextViews, TextSetters, TextControllers. Экспортируются из каждого модуля только интерфейсы, конкретная реализация сокрыта. Если мне нужен будет свой вариант текста, я перепишу реализацию только того класса (из четырех - Model, View, Setter, Controller), которого нужно, при этом для остальных изменение будет соврешенно прозрачным - они знают только интерфейс "соседа". Если мне нужно изменить совсем мелочь, я напишу обертку, которая будет делать эту мелочь, а все остальное перенаправлять экземпляру стандартного класса.
Если в Дельфе без наследования один графический класс не может делегировать запрос на обработку к другому, то тогда ясно, что там без наследования никуда...
Обероновская шина сообщений позволяет динамически делегировать что угодно кому угодно и как угодно... Не создавая при этом жестких статических зависимостей.
