Есть WinAPi проект. Свое создание окон, своя обработка сообщений.
Понадобилось сделать отдельное окошко с контрольными жлеменатми(кнопками, списоками и т.д.) очень не хочется делать это на WinAPI.
Интересует, возможно ли внедрить VCL\LCL в это приложение.
Вернее что возможно - это понятно. Вопрос в том, насколько затратно и  долго.

Без Application это вряд ли. Ведь для того, чтобы создать форму нужно выполнить метод Application. А чтобы форма заработала, необходимо чтобы закрутился цикл обработки сообщений в Application. Как это будет без летального исхода совмещаться с вашим собственным циклом обработки сообщений - непонятно.

Может быть, вам стоит обратиться к знатокам KOL. Говорят, им удалось скрестить ежа с ужом.

Мне сейчас  было сказано, что Application существует всегда, если подключан модуль Forms.
И достаточно вызывать Application.PrecessMessages для корректной обработки сообщений.
Буду проверять.

> @!!ex ©   (13.04.08 15:46)

Предположим, что у Вас все получилось. Но тогда сразу возникает вопрос - если VCL все равно использована, то не потеряло ли смысл все остальное? Вот это: "Свое создание окон, своя обработка сообщений" - ради чего тогда оно надо?

> Предположим, что у Вас все получилось.

Все получилось.


> Но тогда сразу возникает вопрос - если VCL все равно использована,
> то не потеряло ли смысл все остальное? Вот это: "Свое создание
> окон, своя обработка сообщений" - ради чего тогда оно надо?

Нет не потеряло.
Движок используется один и тот же. Что для непосредственно игры, что для просмоторщика моделей(это как раз то, что я сейчас делаю).
Но движок - Full API, а просмоторщик, с LCL формой управления. Для того, чтобы форму из просмоторщика убрать - надо закомментить 10 строк, и останется вполне себе API приложение. Тоже самое с главным проектом. Его можно компилить как полностью API, так и с LCL надстройками.

P.S.
Против LCL Ничего не имею, но движок не буду никогда писать, потому что предпочитаю все контролировать. Уж лучше я напишу пару модулей низкоуровневых, но буду в них уверен.
А LCL оставлю для внутренних проектов, которые дальше нашей конторы не пойдут.

> [4] Семеныч   (13.04.08 16:44)

Вообще изначально подразумевалось, что просмоторщик будет полностью на LCL, но там возник косяк с отрисовкой. Как его решить, не сказали ни на этом форуме, ни на FreePascal.ru.
Поэтому я окно главное рисую средствами API, а контрольку LCL.
Так и не потерял удобства визуального конструирования интерфейса, и при этом сохранил нормальный рендер моделей.

> Но движок - Full API, а просмоторщик, с LCL формой управления.


Запарил ты своим FP. Ну и иди в соотвествующий топик. Тут только VCL обсуждаеться. Application - это просто цикл обработки ключевых событий + десяток обёрток незначительных.

> [7] tesseract ©   (13.04.08 18:44)

Ты модератор? Не устраивает - жалуйся модераторам. Либо проси, чтобы тебе плюсомет дали.
Вопрос не по FP. Application в и дельфи также работает.

> [7] tesseract ©   (13.04.08 18:44)

Даю тебе персональное разрешение мои темы не читать.

> @!!ex ©   (13.04.08 18:34) [5]

>  потому что предпочитаю все контролировать. Уж лучше я напишу
> пару модулей низкоуровневых, но буду в них уверен.

Исходя из объявленных предпочтений можно предположить,
что продолжить писать все на win32 API предпочтительней.

По-краней мере, тратить время на совмещение кислого с мягким,
IMHO, не потребуется, а одно окно, даже со списками, можно создать
путем, например, CreateDialog.

--
Regards, LVT.

> Даю тебе персональное разрешение мои темы не читать.


см


> Leonid Troyanovsky ©   (13.04.08 19:48) [10]


Да и зачем тебе  в 3D формы ?  Напиши свой FW - проще потом баги разгребать. Opnegl+ VCL -  я это врагу не пожелаю.

> [10] Leonid Troyanovsky ©   (13.04.08 19:48)

Это критично для основного проекта, который распространять. А для внутреннего использования можно и LCL юзать.
Просто нужно набросать побыстренькому интерфейс для внутренних утилит, надежность тут не сильно важна.
А вот для внешнего проекта надежность - на первом месте.

> @!!ex ©   (13.04.08 19:55) [12]

> Это критично для основного проекта, который распространять.
>  А для внутреннего использования можно и LCL юзать.

Я не знаю, кто такой LCL (да и нет особого любопытства),
но если требования к внутреннему использованию будут
ниже, чем к внешнему, то внутренние, рано или поздно,
туда прорвутся.

--
Regards, LVT.