Help!!!

← →
romulas (2002-02-13 14:33) [0]

Добрый вечер All!

Вопросик, вот такой....

Есть Dll Написанная на Builder. Нужно в нее передать указатель на TDataSet. Вызываем Dll и .... ничего... Такое впечатление что ничего не передалось... Вызывающ программа написана на Дельфи.

Причем если Вызывающ программа написана на билдере, то все ок

Если использовать такую же dll только написанную на дельфи все ок (ну почти такую же).

Может кто встпечался с этими граблями???

Буду благодарен за помощь, а то жутко переписывать Dll на дельфи не хочется.

← →
Fellomena (2002-02-13 15:37) [1]

Проблема скорее всего в соглашении о вызове, в С она, как известно, _cdecl, а в Паскале pascal
Так что везде в С-ом коде cdecl замени на stdcall и при загрузке dll используй тоже stdcall

← →
romulas (2002-02-13 17:34) [2]

Я изначально всегда использовал соглашение stdcall.

Да нет... К сожалению тут проблема в чем то другом, глобальнее что ли... Если отдебажить, то что приходит в Dll из Builder`a, то в частности указатель на TDataSet внутри себя имеющий, ну условно назовем, подсекцию Data и которая отлична от NULL.

Если же смотреть то что приходит в Dll из Delphi, то эта подсекция Data=NULL.

Тут проблема кажется стоит так: Можно ли в Delphi использовать Dll написанную на Builder`е, которая использует в качестве параметра к экспортируемой функции указатель VCL класс???

Как эти грабли обходятся???

Повторюсь, что Delphi-Delphi и Builder-Builder работают нормально... Не могу только заставить зашуршать "кроссплатформенный" вариант :-(

Может есть какой преобразователь для таких Builder`овских Dll в Delphi...

Всего доброго и спасибо за помощь

← →
Иван Шихалев (2002-02-13 17:44) [3]

Уже на эту тему много говорилось... Надежный вариант - только BPL.

← →
Fellomena (2002-02-14 11:32) [4]

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

Попробуй tdump-ом глянь в таблицу экспорта своей DLL, если там будет что-то типа:

1 0 00001000 ??4MyСlass@@QAEAAV0@ABV0@@Z
2 1 00001020 ?Demo@MyStructure@@QAEHPAD@Z

То продолжим тему - будем с этим бороться ;)

← →
romulas (2002-02-14 14:45) [5]

Да нет с именами все в порядке... Имя функции полностью соответствует тому чему надо...

Стал переписывать на Delphi...

← →
Fellomena (2002-02-15 13:40) [6]

Странно всё это... Ведь, по идее что Builder, что Delphi - один чёрт. Даже библиотека компонент одна.
Обратись к М , может они помогут...

← →
Иван Шихалев (2002-02-15 16:00) [7]

Гм... Библиотека-то одна, только вот реализация разная. Объектные модели различаются принципиально, и различия в коде ядра уже как-то не особо удивляют...

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

← →
Fellomena (2002-02-15 16:10) [8]

2 Иван Шихалев © (15.02.02 16:00):
bpl говоришь... дело в том, что по словам тех, кто их использовал - возникают крайне неприятные проблемы при переходе от одной версии Delphi к другой - каждый раз приходится эти bpl переделывать.
Сама сказать ничего не могу - потому что с ними не работала... и не собираюсь пока.
Как мне, к примеру, подключить расчётный модуль, находящийся в bpl к проекту, написанному на VF ? Никак ! А dll можно. Вот.

Но как вариант выхода из конкретного затруднительного положение bpl подходит imho.

← →
Иван Шихалев (2002-02-15 16:16) [9]

> возникают крайне неприятные проблемы при переходе
> от одной версии Delphi к другой - каждый раз приходится
> эти bpl переделывать.

И с чем это связано? Точно по тем же причинам и будут глючить обсуждаемые стыковки Builder+Delphi через DLL со ссылками на объекты, причем гораздо серьезней.

Была тут где-то ветка... Но повторюсь: DLL - это механизм разделения функций, а никоим образом не классов.

← →
Fellomena (2002-02-15 16:31) [10]

Угу... Строго говоря DLL о существовании классов вообще не "знает".
Но и с этим борятся вроде как-то 8)
А проблемы заключаются в том, что при переходе к другой версии ново-написанные программы не хотят работать со сарыми bpl (почему и так ли это не знаю - не работала)

← →
Иван Шихалев (2002-02-15 16:49) [11]

Разные версии ядра объектной модели (грубо говоря, TObject) и в том и в другом случае. Бороться можно лишь декларацией интерфейсов, что зачастую неплохо, и позволяет работать с разными языками разных производителей.

Но возвращаясь к начальному сообщению - такое использование DLL - еще большая проблема, чем BPL разных версий.

← →
Digitman (M) (2002-02-15 17:02) [12]

>romulas
Читаю вот я полемику эту и думаю : f что же, попросту говоря, мешает тебе, имея оригинальный CBuilder-проект, установить брейкпойнт на точку входа в "проблемную" DLL-ф-цию, "поймать" ее в run-time да посмотреть средствами встроенного дебаггера CBuilder"а, что же там , собственно, передается в параметре, "призванном" передавать объектную ссылку как таковую ?

← →
romulas (2002-02-15 19:27) [13]

А ничего не мешает... Я так и сделал... Так вот то что я там увидел мне совершенно не понравилось, указатель просто никуда не указывает.. Вот и все... :-(((

← →
romulas (2002-02-15 19:41) [14]

Спасибо всем кто ответил!!!
Частично проблема снимается просто добавлением в вызывающей программе ShareMem...

← →
Digitman (M) (2002-02-16 16:12) [15]

>>"..просто никуда не указывает"
Как это понимать ? что отладчик показывает ? NULL ? NIL ? или -что ?

← →
[NIKEL] (2002-02-16 16:29) [16]

а что делает эта dll ? может тебе просто переписать ее на Паскаль...

Help!!! Найти похожие ветки