Система упрощенного создания окон (S.C.O.W.)

[pu4koff]

Сообщение от Alex Cones

Для сравнения - сколько потребуется строк кода, чтобы нарисовать на форме додж? Ответ: 10:

CreateApplication;
 FRMMain.Left := 10;
 FRMMain.Top  := 10;
 FRMMain.Width := 300;
 FRMMain.Height := 188;
 CreateForm(FRMMain, 'Small Fonts', 9);
 ShowForm(FRMMain, TRUE);
 LoadTexture(FRMMain, 'Dodge.bmp', 'Dodge');
 Draw(FRMMain, 'Dodge', 0, 0, TRUE);
 BufferDraw(FRMMain);

Могу сказать, что 10 строк унылого, некрасивого, непонятного кода.
Теперь более подробно:
1) CreateApplication выглядит лишним. При создании программы я мысленно уже создаю приложение, зачем мне его еще вручную создавать, да без всяких параметров?
2) Формы еще нет, а мы уже меняем её размеры и положение. Не логично;
3) CreateForm создано в процедурном стиле, т.е. в библиотеке просматривается помесь чего-то с чем-то. Метод Create выглядел бы более родным в ОО коде. Да даже не метод, а конструктор;
4) ShowForm - аналогичная процедурность. FRMMain.Show, FRMMain.Hide выглядели бы логичнее, понятнее и краше;
5) LoadTexture - про процедурность и моё к ней отношение уже все всё поняли я надеюсь. Зачем мы привязываем текстуру к форме? Эта две отдельных единицы, которые могут существовать отдельно, а тут получаем зависимость. Придется одну и ту же картинку дублировать на разных формах;
6) Draw - не айс. Допустим, нужно реализовать градиентный фон, одноцветный, текстуру, "плитку",... В итоге получим разный код заполнения фона? Некрасиво, неправильно;
7) BufferDraw - вообще не понял сути строчки. Удобства она явно не прибавляет.
Вывод: судя по этим строкам, библиотека получается еще более унылой, нежели VCL. Не модно сейчас так делать, старо, есть куча аналогов. Смысл делать очередную поделку? Если бы это был WPF под Delphi или HTMLayout, то без базара, а так... разве что для получения опыта.

[Alex Cones]

Допустим, нужно реализовать градиентный фон, одноцветный, текстуру, "плитку"

В ближайшее время собираюсь перенести эффекты FVFL в движок.

2) Формы еще нет, а мы уже меняем её размеры и положение. Не логично;

Мы заполняем данные - как мы создадим форму, не указав размеры и положение? Можно, конечно в процедуре указать, но зачем её усложнять? Если Вы привязываете размеры формы к вычислениям Вам придется вводить новые переменные, а так - нет.

[pu4koff]

Сообщение от Alex Cones

Мы заполняем данные - как мы создадим форму, не указав размеры и положение? Можно, конечно в процедуре указать, но зачем её усложнять? Если Вы привязываете размеры формы к вычислениям Вам придется вводить новые переменные, а так - нет.

При проектировании никогда не задумывайтесь о сложности реализации. Хотите создать удобный код - думайте об удобстве использования, а не реализации.
В VCL вот так форма создаётся, если мне не изменяет память:

with (TForm.Create()) do // Создаём форму
  Left := 10; // Изменяем позицию
  ...  // Делаем что-то еще
  Show; // Отображаем
end;

Как по мне, так более красиво и изящно получается, нежели в сабже.

Ну а вообще... Библиотека должна иметь свою атмосферу, если хотите. Изначально нужно определить что есть приложение в данной библиотеке, что есть форма, ... Плевать на устройство всего этого в винде. Ну и что, что кнопка окном является по сути, в библиотеке кнопки могут вообще быть отдельной единицей со своим устройством. Свойства, события... всё это повторение уже существующего материала. Всё это реализовано, работает и сильно лучше и удобнее на этой базе вряд ли что-то получится. А может форме события и не нужны? Ну есть она, какие-то кнопочки на ней, причем здесь нажатия кнопочек мыши, "горячие" клавиши,... Может тут нужна отдельная единица "форменный управлятор"? Прикрутили отдельный объект к форме и он следит за нужными событиями и делает что нужно? Или как в Java: реализовали нужный интерфейс - значит форма следит за нажатиями мыши, а иначе - они по барабану.
В общем, хотите, чтобы велосипед взлетел - мыслите нестандартно, ищите новые подходы, новые парадигмы.

[Alex Cones]

В общем, хотите, чтобы велосипед взлетел - мыслите нестандартно, ищите новые подходы, новые парадигмы.

Не в этом суть. Приведу пример:
Сегодня на хабре шло обсуждение, что индикатор раскладки винды не удобен:

http://habrahabr.ru/blogs/ui_design_...bility/107732/
И? Хоть один сказал что-то про мой индикатор? НЕТ! Это дело пиара и только пиара. Будь система в десять раз неудобней - если её распиарят найдутся миллионы поклонников, которые не будут признавать ничего другого.

[BOBAH13]

Alex Cones - у вас очень плохая привычка, вы игнорируете и видите только то что хотите. Я, и еще вот один человек pu4koff, а вы увидели проблему только в 2ом вопросе. А к примеру 1й, я уже писал решение про Signleton к примеру.

Ну я в принципе не удивлюсь если вы и этот пост проигнорируете.

[ROD]

Мы заполняем данные - как мы создадим форму, не указав размеры и положение?

Могу прдложить такой вариант:
Подразумеваем под FormCreate что-то типа создания некого нового объекта, без его описания (реально формы никакой еще нет, но мы подразумеваем, что она есть, и задаем параметры, которые будут у формы, когда мы ее создадим (см. далее)), фактически что-то типа создания структуры, описывающей форму.

А вот ShowForm "реально" создает форму, т.е. регистрирует ее и т.п. (я тут плаваю в терминах, ибо WinAPI знаю плохо) (если она не была создана раньше) и показывает ее (в любом случае).

[Levsha100]

Мы заполняем данные - как мы создадим форму, не указав размеры и положение?

Можно попытаться в начале прочитать файлик конфы, и если его нет по дефолту выставить параметры.

[Alex Cones]

Вопрос к аудитории - т.к. визуальными эффектами пользователь будет пользоваться не часто, имеет ли смысл вынести их в отдельную dll? Или оставить в основной? А то они весить мно-о-о-ого будут.

[Utkin]

Много это сколько?

[Alex Cones]

Ну сейчас основная dll проекта весит 20 с копейками. После импорта эффектов будет весить приблизительно 60-70. Прикидываю по FVFL.