Для этого надо уметь пользоваться MSDN и уметь программировать на чистом WinAPI. Это не только довольно сложно, но и не очень нужно. Особенно в свете многоплатформенности.
Я не говорю про откат на winapi. Просто сделать lcl приложение с рантайм созданием форм и их содержимым. Xотя конечно понимать что всё это "обертка" и в конечном итоге работает winapi|qt|gtk тоже не помешает))
Разве для этого нет компонент? В одном из моих последних проектов напарник просто что-то кинул на форму, и все вышеперечисленное стало доступно.
что-то кинул на форму, и все вышеперечисленное стало доступно.
Вот про это я и говорю - чтото... гдето...
А между прочим дельфевый код, что написан в onЧетоТам более соотвествует принципам ООП, чем изредка наблюдаемый код той-же явы, в которой, как мне известно, и принято размыливать бизнес-код UI-логикой
Раз уж вы так ратуете за разделение - в onЧетоТам быть ничего не должно кроме вызова mySuperBusinessUnit.mySuperBusinessProc(...) или еще лучше юзать то, что для этого предназначено в LCL|VCL - TActions.
Тогда можно поговорить о разделении, а извиняюсь загрузка чего бы то ни было спрятаная в TmyForm.OnLoadButtonClick - это каша а не разделение
Чтоб понять это, достаточно обявить свой TForm=class(TMyForm) и TEdit=class(TMyEdit), где TMyForm и TMyEdit вовсе не наследники вкл, и проект на onЧетоТам и кучи EditNN станет из визуального, скажем консольным.
Уже пробовали?)) гораздо логичней как я написал в предидущем цитировании
И все эти превращения - без переписывания кода, что есть не только тру ООП, но и большой гуд проекту с точки зрения надежности.
С описаным вами подходом это мягко сказать - неправда, и даже если в итоге ценой ненужных копипастений вы получите рабочее консольное приложение - это будет хрень. TForm это гуй, она предпологает организацию и способы работы свойственные гую, тянет за собой кучу нигде не нужных кроме гуя зависимостей... и т.д. и т.п. А самое главное, сама по себе НИКАК НЕ ОБЕСПЕЧИВАЕТ РАЗДЕЛЕНИЕ "UI-логики с бизнес-логикой"
Как бизнес код, смешанный в кодом работы визуальных элементов, может стать компактнее?
Кто заставляет его мешать? создать чтото в рантайме значит смешать?
Создаем в дизайнере нцать TEdit`ов, каждый тыкаем мышкой и настраиваем в инспекторе как надо, недай бог потом придется перенастроить... рутина? Думаем как это можно оптимизировать - а никак, кроме как запилить в лазаре работу с множественным выбором компонентов в инспекторе...
Создаем в рантайме нцать TEdit`ов, каждый кодом настраиваем как надо... рутина? Думаем как это можно оптимизировать - да хоть как, например пиши универсальную процедуру создания однотипных компонентов
Я про вот это говорю.
Щас вы конечно скажете что формы сложные, не унифицируются... потому и сложные что сделаны в дизайнере
Добавлено спустя 19 минут 34 секунды:Никакой магии, вызовы то происходят из разных контекстов. В данном случае разность контекстов будет определяться выдимостью типов.
никакой, TReader.FindComponentClass имеет ссылку на созаваемую форму, в список пропертей которой попал наш подмененный tedit, оттуда берутся и адрес конструктора и указатель на vmt подмененного tedit и осуществляется вызов нужного нам конструктора с нужным нам скрытым параметром в виде его вмт.
Что вы подразумеваете под разницей контекстов? rtl\objpas\classes\reader.inc давно скомпилирован вместе с fpc и ничего о новом классе незнает
вы хотите сказать что вызовы TEdit.Create и TмуEdit.Create абсолютно одинаковы и по адресу и по параметрам? нет, это не так
В экземпляре класса нследника есть ссылка на родительскую вмт.
Есть, только она нужна для работы inherited, is, возможно as и подобного. В данном случае это не имеет значения
