О загрузке runtime package

[Ins]

экспорт интерфейсов и только com-безопасные типы в параметрах методов

Ах, да, и safecall-методы, иначе объект (Exception) и без твоего желания перейдет границу exe-dll. И как это GunSmoker меня не поправил?

[Stilet]

Это как, is-ом, что-ли?

Именно им.

[Ins]

Именно им.

Ну попробуй. А потом, когда ничего не получится, вернись на предыдущую страницу и почитай мое сообщение #16, чтобы понять из-за чего

[Stilet]

Ins

Хорошо. Встречный вопрос "Мне пришел из ДЛЛ некий наследник TObject. Чем мне узнать что это за класс?"

И кстати, Я вообще-то не оч. понимаю зачем понадобилось с GetClass связываться.
По-моему проще сделать что-то вроде:

  function LetO(type_:string):TObject;
  begin
   if type_='sl' then begin
    Result:=TObject(TStringList.Create);
   end;
  end;

И работать с ней

begin
  b:=TStringList(LetO('sl',self));
  b.Add('adad');
  ListBox1.Items.AddStrings(b);
end;

Все равно автору ДЛЛки известны какое классы он использует, или я не прав?

[GunSmoker]

Сообщение от Ins

И как это GunSmoker меня не поправил?

Как-то не дочитал ещё, да...

[GunSmoker]

Сообщение от Stilet

"Мне пришел из ДЛЛ некий наследник TObject. Чем мне узнать что это за класс?"

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

Вон там у автора поста был пример с формой (что-то я сейчас подумал: будет ли это работать, ведь форме нужен DFM, который сидит в DLL, а не в exe, откуда мы создаём экземпляр). Видимо, DLL у него - что-то вроде плагина.

[Ins]

Чем мне узнать что это за класс?

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

По-моему проще сделать что-то вроде:

Значит понятия "абстрактная фабрика", "фабричный метод" для тебя новые... Не проще. Полиморфизм служит как раз для того, чтобы избавиться от условной логики, в данном случае речь идет о полиморфном инстанцировании.

[Stilet]

Значит понятия "абстрактная фабрика", "фабричный метод" для тебя новые

Новые. Я свои задачи решаю успешно и без таких глубин. А когда имею дело с ДЛЛ предпочитаю четко описать как я показал все что хочу.

для того, чтобы избавиться от условной логики

Меня она не напрягает.

[Ins]

Меня она не напрягает.

Я заметил. До того, чтобы она стала напрягать, нужно cозреть. Тогда длинные case-ы и блоки if-ов легким движением руки превращяются в виртуальные методы, а оператор "is" практически вообще выходит из арсенала из-за ненадобности А смысл? А смысл в том, что программист должен быть ленивым (это относится только к работе руками, а не головой), и писать минимум кода при максимуме надежности и эффективности

[Greek9000]

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

Однако, для полного просветления осталось выяснить ещё один тонкий момент (тем более, что он не противоречит теме поста).

Если скомпилировать проект с галочкой Compile with Runtime Package и в строке со списком пакетов оставить только vcl и rtl, после чего посмотреть сводную информацию по проекту (Project->Information for ...), то в колонке Packages отобразятся только эти два пакета. Оно и понятно - что указали, то и подключили. Но если оставлять все пакеты, которые установлены в IDE могут появляться ошибки (напр. у меня установлены JEDI-компоненты и при компиляции выскакиваю ошибки, типа "не найден пакет такой-то" или "пакет такой-то не является run-time-пакетом"). Поэтому я открываю сводную статистику по проекту и смотрю какие вызовы у меня происходят без пакетов. Потом всякими правдами и неправдами выясняю в каких пакетах находятся эти вызовы и дописываю их в список подключаемых пакетов.

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

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