Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2009.01.25;
Скачать: [xml.tar.bz2];

Вниз

Выбор структуры приложения с использованием пакетов   Найти похожие ветки 

 
{RASkov} ©   (2008-11-30 22:02) [0]

Будьте добры, подскажите пожалуйста как лучше осуществить вот какую задумку:

Хочу попробывать научится использовать пакеты(BPL) в приложениях.
На сей момент задумка такая. Есть программа(exe)-загрузчик. Из себя представляет обычное приложение по умолчанию в делфи.
Т.е. одна главная форма, на ней.... (вот тут вопросик что лучше?) Я пока остановился на TTabControl. Как вариант TPageControl или.... ??
Суть такая: Форма, вверху закладки, так вот содержимое закладок должно быть в bpl"ках...

Все это должно быть в динамике, добавили bpl в папку с плагинами, появилась новая закладка при следующем старте программы-загрущика...
т.е. при старте приложения-загрузчика просматриваются файлы bpl и если пакет содежит "вкладку" (тут тоже вопрос), то добавить в
TabControl1.Tabs.Add(имя вкладки из пакета).... так вот вопрос что лучше в пакете использовать.... Я пока остановился на TFrame...

Вообщем у меня пока дуратское сообщение о том, что TFont не совместим c TFont.... :) Это мне уже знакомо, думаю разберусь, но вот подскажите вообще идеи по данной задумке.


 
Сергей М. ©   (2008-11-30 22:07) [1]


> у меня пока дуратское сообщение о том, что TFont не совместим
> c TFont.... :) Это мне уже знакомо


Притча о граблях)


> подскажите вообще идеи по данной задумке


Нормальная вполне себе задумка.
Если с граблями отношения выяснить раз и на всегда.


 
monogandhi   (2008-11-30 22:22) [2]

Пакеты - это просто #%!@#%^#@#$! какой-то. Неужели для того, чтобы использовать собственного потомка некоторого визуального компонента мне нужно оформлять его в виде отдельного пакета, отдельно компилировать и прочая и прочая?
Это же морока какая и умножение сущностей без всякой меры.


 
Сергей М. ©   (2008-11-30 22:25) [3]


> Неужели для того, чтобы использовать собственного потомка
> некоторого визуального компонента мне нужно оформлять его
> в виде отдельного пакета


Нет.


> отдельно компилировать


Да. А как же без компиляции ? Без нее никуда)


> и прочая и прочая


В Коране об этом ничего не сказано)


 
monogandhi   (2008-11-30 22:27) [4]

Сергей М. ©   (30.11.08 22:25) [3]

А разъясните, пожалуйста, тогда как. Я пробовал просто отнаследовать и в dfm имя подменить, мне сказали чтобы больше так не делал. Пришлось делать пакет.


 
monogandhi   (2008-11-30 22:27) [5]

monogandhi   (30.11.08 22:27) [4]

Имеется в виду, среда ругалась на сие непотребство.


 
{RASkov} ©   (2008-11-30 22:29) [6]

> [1] Сергей М. ©   (30.11.08 22:07)

Т.е. так и оставить (TTabControl в программе) и (TFrame в пакете) ?

>>>>
И если можно, коротко о граблях, пожалуйста... хотя бы о "TFont не совместим c TFont"
т.е. как правильно создать в пакете фрэйм, и как его поместить на TTabControl...?


> [2] monogandhi   (30.11.08 22:22)
> Пакеты - это просто #%!@#%^#@#$! какой-то.

Зря ты так.... я тоже раньше был такого же мнения, но... :)


 
Сергей М. ©   (2008-11-30 22:30) [7]

A причем здесь dfm ?
Компоненты не нуждаются ни в каких dfm"ах - они прекрасно рождаются существуют сами по себе.


 
monogandhi   (2008-11-30 22:33) [8]

Сергей М. ©   (30.11.08 22:30) [7]

Вы что-то все уклончиво говорите. В [2] говорилось о потомке некоего визуального компонента из некой сторонней библиотеки (то есть стороннего пакета, который уже был установлен). Он присутствовал на форме, то есть инстанциировался средой. Насколько я понимаю, для этого нужно указывать его тип. Этого как раз и не удалось сделать.


 
Сергей М. ©   (2008-11-30 22:37) [9]


> {RASkov} ©   (30.11.08 22:29) [6]


exe должен быть собран с опцией использования ран-тайм пакетов - вот и вся премудрость граблей


 
Сергей М. ©   (2008-11-30 22:39) [10]


> В [2] говорилось о потомке некоего визуального компонента
> из некой сторонней библиотеки (то есть стороннего пакета,
>  который уже был установлен). Он присутствовал на форме,
>  то есть инстанциировался средой.


В [2] об этом нет ни слова, не надо выдумывать задним числом.


 
monogandhi   (2008-11-30 22:42) [11]

Сергей М. ©   (30.11.08 22:39) [10]

Цитирую себя же, простите.

>Неужели для того, чтобы использовать собственного потомка некоторого визуального компонента мне нужно

Выходит, его нужно инстанциировать динамически без всякого упоминания в форме?
Тогда мы теряем все прелести визуального редактирования свойств (компонент может быть достаточно сложным, но что делать, пакеты...


 
Сергей М. ©   (2008-11-30 22:47) [12]

Повторяю эту цитату:


> использовать собственного потомка некоторого визуального
> компонента


Для этого достаточно объявить и реализовать наследника этого компонента. Где он будет объявлен, реализован и использован - об этом речь не шла. Равно как не шла речь и конкретно о дизайн-тайм.


 
{RASkov} ©   (2008-11-30 22:51) [13]

> [9] Сергей М. ©   (30.11.08 22:37)

так... но тогда тут получается EXEшник маленького размера, т.е. нужно будет все библиотеки VCL прикладывать к екзе....
А как сделать так, чтоб экзешнику не требовались никае внешние(VCL) БПЛ....?


 
Сергей М. ©   (2008-11-30 22:51) [14]


> его нужно инстанциировать динамически без всякого упоминания
> в форме?


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


 
monogandhi   (2008-11-30 22:53) [15]

Сергей М. ©   (30.11.08 22:47) [12]

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


 
Сергей М. ©   (2008-11-30 22:54) [16]


> {RASkov} ©   (30.11.08 22:51) [13]


> тут получается EXEшник маленького размера, т.е. нужно будет
> все библиотеки VCL прикладывать к екзе


И что этому мешает ?


> как сделать так, чтоб экзешнику не требовались никае внешние(VCL)
> БПЛ....?


Собрать без вышеупомянутой опции.
Но тогда придется распрощаться с изначальной идеей-фикс)


 
monogandhi   (2008-11-30 22:54) [17]

Сергей М. ©   (30.11.08 22:51) [14]

Можно ли это сделать, не создавая пакет, и если да, то как?


 
{RASkov} ©   (2008-11-30 22:57) [18]

> [16] Сергей М. ©   (30.11.08 22:54)
> [13] {RASkov} ©   (30.11.08 22:51)

если я ставлю данную галку и очищаю строку со списком бплок, то галка снимается.... и опять тажа ошибка :(
можно конечно оставить какой-нибудь пакет и его дополнительно положить в папку с программой.... например специально для этих целей подготовленную...
Но так не верно наверное, или как? :)


> И что этому мешает ?

Ну, не.... я так не расчитывал :)


 
{RASkov} ©   (2008-11-30 22:58) [19]

> [18] {RASkov} ©   (30.11.08 22:57)

т.е. там под галкой есть строка со списком бпл... вот там можно оставить одну какую-нибудь и положить ее к программе в папку...


 
Сергей М. ©   (2008-11-30 22:58) [20]


> monogandhi   (30.11.08 22:53) [15]
>
> Сергей М. ©   (30.11.08 22:47) [12]
>
> Речь шла о том, нужно ли для этого делать пакет


Пакет нужен, прежде всего, в дизайн-тайм, коль речь зашла о dfm.


> Без создания пакета, он не появится на вкладках с компонентами


> Выходит, что пакет создавать таки нужно. А вы говорите что
> не нужно


А у тебя что, язык не поворачивается сказать, что речь изначально идет о дизайн-тайм ?

Для дизайн-тайм пакет обязателен, для ран-тайм не обязателен.


 
{RASkov} ©   (2008-11-30 23:02) [21]

> monogandhi

Что мне тут все портишь??? :)
Заведи себе свою ветку )))


 
monogandhi   (2008-11-30 23:03) [22]

Сергей М. ©   (30.11.08 22:58) [20]

Простите, два раза я обращал ваше внимание на то, что компонент визуальный.

{RASkov} ©   (30.11.08 23:02) [21]

Прошу меня извинить, измучался просто с этим весь.


 
Сергей М. ©   (2008-11-30 23:03) [23]


> {RASkov} ©   (30.11.08 22:57) [18]


> ставлю данную галку и очищаю строку со списком бплок


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


> можно оставить одну какую-нибудь и положить ее к программе
> в папку


Тебе что, все равно какую ?)


 
Сергей М. ©   (2008-11-30 23:05) [24]


> два раза я обращал ваше внимание на то, что компонент визуальный


И что ?

Визуальный компонент м.б. инстанцирован как в ран-тайм, так и в дизайн-тайм.
Вопрос лишь в том, автоматически ли это делается или вручную.


 
monogandhi   (2008-11-30 23:11) [25]

Сергей М. ©   (30.11.08 23:05) [24]

Да, я уже высказал свою догадку об этом в [11], не пытайтесь защищаться, ваша позиция видна насквозь.
В моем случае проще морочиться с пакетом. Но не будем же побивать друг друга словесами неприличными. Мира, добра и счастья вам.


 
{RASkov} ©   (2008-11-30 23:16) [26]

> [23] Сергей М. ©   (30.11.08 23:03)
> А зачем ты ее чистишь всю ?

Хотел, чтоб стандартные прилинковались к экзе, и все былоб как обычно.... и только мои БПЛки подгружались бы динамично.... если имеются.
не к чему таскать все стандартные пакеты.... я так не планировал :(


> Тебе что, все равно какую ?)

ну да... например я оставил только последнюю из того списка dclOfficeXP.... но вот сейчас глянул на размер экзе и огорчился.... он такой же маленький :( т.е. библиотеки так и остались не прилинкованные....

Вопрос:
если эту галку [9] не ставить то никак не избавится от этих граблей, например о которых я указал в [0](TFont)?


 
Сергей М. ©   (2008-11-30 23:19) [27]


> В моем случае проще морочиться с пакетом


Что это за "твой случай" такой ?
Ты для кого все это затеял - для себя лично или для будущих сторонних разработчиков-пользователей своего компонента ?


 
monogandhi   (2008-11-30 23:24) [28]

Сергей М. ©   (30.11.08 23:19) [27]

Если вам интересно, то имеется некоторый нетривиальный компонент для визуального представления данных, написанный сторонними разработчиками.
Требуется некоторым нетривиальным образом изменить поведение его субкомпонентов. Наиболее просто это можно сделать, создав потомка.
Однако при этом, проект начинает размазываться по пакетам... Насколько я понимаю, для Дельфи это стандартная практика?


 
Сергей М. ©   (2008-11-30 23:26) [29]


> {RASkov} ©   (30.11.08 23:16) [26]



> ставил только последнюю из того списка dclOfficeXP


Любая прикладная bpl, поскольку она безусловно собирается с ран-тайм пакетами, использует стандартные bpl, которые автоматически подключаются к проекту, использующему эту прикладную bpl.
Как минимум это rtl и vcl.

В противном случае нафих нужны такие пакеты, если они будут дублированы в АП процесса ?


 
Сергей М. ©   (2008-11-30 23:29) [30]


> Наиболее просто это можно сделать, создав потомка


Если есть исх.тексты ориг.компонента, то гораздо проще изменить их - в этом случае плодить пакеты не придется.


> для Дельфи это стандартная практика?


Да.


> проект начинает размазываться по пакетам


Не понимаю, почему тебя это так сильно заботит ..


 
Сергей М. ©   (2008-11-30 23:34) [31]


> monogandhi


я надеюсь, ты в курсе, что собранный проект может не использовать bpl ?
Тогда о каком "размазывании" идет речь ?


 
monogandhi   (2008-11-30 23:38) [32]

Сергей М. ©   (30.11.08 23:34) [31]

Нет, об этом я ничего не знаю. Что значит "собранный проект"?
К сожалению, структуру проекта (за исключением добавления новых проектов в группу) я изменять не могу.


 
Сергей М. ©   (2008-11-30 23:38) [33]


> Пакеты - это просто #%!@#%^#@#$! какой-то


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


 
{RASkov} ©   (2008-11-30 23:39) [34]

> [29] Сергей М. ©   (30.11.08 23:26)
> В противном случае нафих нужны такие пакеты, если они будут
> дублированы в АП процесса ?

Зачем? Я расчитывал, что Екзе соберется как обычно со всеми необходимыми библиотеками, а вот плагины, в виде пакетов, подгружались бы при необходимости и наличии в папке с палагинами....
Ведь с dll это еще сложнее... Т.е. пакетами хотел заменить DLL, но тут опять не все гладко :)
Что-то тут не так...


 
Сергей М. ©   (2008-11-30 23:44) [35]


> Что значит "собранный проект"?


Результ сборки проекта - это модуль, содержащий как минимум исполняемый код, реализующий требуемую проектом функциональность.
В зависимости от типа Win-проекта результатом м.б. EXE- или BPL- или DLL-модуль.


> структуру проекта (за исключением добавления новых проектов
> в группу) я изменять не могу


А где тогда ты объявляешь и реализуешь наследника того самого компонента ?
Прямо в юните ориг.разработчика ?


 
Сергей М. ©   (2008-11-30 23:47) [36]


> {RASkov} ©   (30.11.08 23:39) [34]


> пакетами хотел заменить DLL


И правильно !


> Екзе соберется как обычно со всеми необходимыми библиотеками


Он так и соберется, если ты поставишь ту самую галку.
А библиотеки эти ты просто включишь в инсталл.дистрибутив своего приложения.


> плагины, в виде пакетов, подгружались бы при необходимости


Кем подгружались-то ?
И что этому мешает ?


 
Petr V. Abramov ©   (2008-11-30 23:48) [37]


> Зачем? Я расчитывал, что Екзе соберется как обычно со всеми
> необходимыми библиотеками, а вот плагины, в виде пакетов,
>  подгружались бы при необходимости и наличии в папке с палагинами.
> ...

а плагины библиотеки не используют? раз TFont испльзуется, то используют.
и будет у тебя столько вариантов класса TFont, сколько плагинов. и при достижении какого-то (небольшого, зависящего от кол-во используемых классов) числа пакетов таскать vcl-bpl станет просто выгодней


 
monogandhi   (2008-11-30 23:53) [38]

Сергей М. ©   (30.11.08 23:44) [35]

Я вижу мы не понимаем друг-друга, из-за недостаточно развитой способности к телепатии.
Телепатически интерпретируя, я предполагаю, что говоря о том, что "собранный проект может не использовать bpl" вы говорите, возможно, о рантайм подключаемых bpl.
В этом проблем нет, и все равно какие использовать. Проблема в принципиальном умножении сущностей и мороке при установке пакетов другими разработчиками при добавлении пакетов кем-либо из них (иные среды разработки лишены этого недостатка).
Под изменением структуры проекта подразумевается удаление, слияние, значительное изменение функциональности каких-либо жизненно важных сущностей.
Тренируйте телепатор, пожалуйста.


 
{RASkov} ©   (2008-11-30 23:59) [39]

> [36] Сергей М. ©   (30.11.08 23:47)

> [37] Petr V. Abramov ©   (30.11.08 23:48)

А как тогда узнать список всех бпл, которые необходимы для конкретного проекта.... не класть же все подряд туда... в папку с программой. Дистрибутива как такового не будет, не будет ни какой инсталяции, просто папка с екзе и плагинами(пакетами) + пакеты VCL ...но не все.

Или "в ручки" по всем uses пройтись и составить список пакетов? :) Что-то мне все меньше и меньше нравится эта идея с пакетами :( ...а куда деваться... :)


 
{RASkov} ©   (2008-12-01 00:00) [40]

> [37] Petr V. Abramov ©   (30.11.08 23:48)
> а плагины библиотеки не используют? раз TFont испльзуется,
> то используют.

в плагинах TFrame с контролами и функционалом....



Страницы: 1 2 вся ветка

Форум: "Прочее";
Текущий архив: 2009.01.25;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.57 MB
Время: 0.017 c
2-1228895475
9899100
2008-12-10 10:51
2009.01.25
PolyLine


1-1207310024
TStas
2008-04-04 15:53
2009.01.25
Как добавить в ActionList Action?


3-1213855653
deodora
2008-06-19 10:07
2009.01.25
приложения для редактирования таблицы на MySQL сервере


2-1228827584
9899100
2008-12-09 15:59
2009.01.25
TCanvas


1-1206987467
Efir
2008-03-31 22:17
2009.01.25
Открыть несколько выбранных файлов





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский