Мистика при получении результата из dll

← →
Антоныч © (2005-11-17 15:13) [0]

Я пишу dll-ку, которая подключается к БД и возвращает результат в виде списка (массива записей). В дальнейшем dll будет подключаться к 1С, поэтому не использую модуль ShareMem, а строковые значения передаю через PAnsiChar. Тут обнаружил интересную вещь. Допустим, эспортируемая функция имеет вид:
function GetMaterList(DBPath, SZ: PAnsiChar): PAnsiChar; Export; stdcall;
var
ZT: TTable;
...
Result:=PAnsiChar(ZT.Fields[1].AsString);

Получается Access Violation. Причём, если просто написать Result:=PAnsiChar("Проверка") - всё нормально работает. Пробовал делать тип возвращаемого результата Integer, затем Result:=ZT.Fields[0].AsInteger - всё отлично. Проблема именно с AsString. Подскажите, где может быть ошибка.

← →
DesWind © (2005-11-17 15:16) [1]

Мож память надо под результат выделить?

← →
Leonid Troyanovsky © (2005-11-17 15:21) [2]

> DesWind © (17.11.05 15:16) [1]
> Мож память надо под результат выделить?

Не мож, а нуж.
Еще лучше, если это делать в том самом,
вызывающем библиотеку приложении.

--
Regards, LVT.

← →
Антоныч © (2005-11-17 15:23) [3]

Может, и надо :). Но тогда получается, что при Result:=PAnsiChar("Проверка") память выделяется автоматически? Просто, честно говоря, не особо в этом пока что силён.

← →
Vlad © (2005-11-17 15:25) [4]

> Антоныч © (17.11.05 15:23) [3]

Если я правильно понял, твоя функция возвращает результатом указатель на локальную переменную функции (ZT) ?
Что компилятор сделает с переменной ZT при завершении функции? Уничтожит. Значит ты возвращаешь заведомо "битый" указатель.
См [1]

← →
Ega23 © (2005-11-17 15:26) [5]

StrAlloc
StrCopy
StrDispose

← →
Digitman © (2005-11-17 15:31) [6]

> В дальнейшем dll будет подключаться к 1С

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

← →
Leonid Troyanovsky © (2005-11-17 15:46) [7]

> Антоныч © (17.11.05 15:23) [3]
> Может, и надо :). Но тогда получается, что при Result:=PAnsiChar("Проверка")
> память выделяется автоматически? Просто, честно говоря,
> не особо в этом пока что силён.

Учитывая последнее надо требовать от приложения, чтобы
оно само заботилось о буфере для результата.
Для большинства разработчиков, сталкивавшихся с Win32 API
эта ситуация знакома (например, вызов GetComputerName).

А внутри своей dll можно пользовать хоть String.
Только, перед возвратом результата следует оную строку скопировать
в переданный буфер, т.е., Move(s[1], p^, Length(s) {+1})
где p: PChar - адрес переданного буфера.

Ну, и, конечно, внимательно следить за тем, чтобы не вылезти
за границы переданного буфера, а в качестве результа функции
возвращать, например, кол-во реально скопированных символов.

--
Regards, LVT.

PS PAnsiChar("Проверка") - означает адрес (распределенной) константы.

← →
Digitman © (2005-11-17 15:52) [8]

> Leonid Troyanovsky © (17.11.05 15:46) [7]

все это замечательно, но при этом есть 1С Add-In SDK, где четко и по-русски оговаривается, что и как должен делать внешний по отношению к 1С модуль для обеспечения корректного обмена инф-цией.

← →
Digitman © (2005-11-17 16:11) [9]

> Антоныч © (17.11.05 15:13)

существует официальный документ

"1С:Предприятие. Технология создания внешних компонент"

он вполне доступен и в Сети и на компактах (при штатной подписке).

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

← →
Гаврила © (2005-11-17 17:22) [10]

Антоныч © (17.11.05 15:23) [3]
Просто, честно говоря, не особо в этом пока что силён.

Если не силен, замени везде Pchar на WideString, и париться с контролем над выделением \ освобождением памяти не придется

← →
Leonid Troyanovsky © (2005-11-17 18:16) [11]

> Digitman © (17.11.05 15:52) [8]

> все это замечательно, но при этом есть 1С Add-In SDK, где
> четко и по-русски оговаривается, что и как должен делать
> внешний по отношению к 1С модуль для обеспечения корректного

Ну, я, честно говоря, даже не подозревал, что 1С так серьезно
относится ко внешним по отношению к нему модулям.

Т.е., мои рассуждения относились к тому, что если из этого
приложения можно делать вызовы из внешних библиотек, то эти
вызовы д.б. не хуже рассмотренных. Например, для VBA оно так
(add-in и прочий COM я даже не брал в расчет).

Ну, а если оный API рекомендован, то, само-собой, его надо
всенеукоснительно блюсти, бо, иначе, даже не на кого
будет пожаловаться.

--
Regards, LVT.

> он вполне доступен и в Сети и на компактах (при штатной подписке).
и где это он доступен? ;о)
в свое время покупали -16$, хотя может и изменилось сейчас, давно было.

> Leonid Troyanovsky © (17.11.05 18:16) [11]
> add-in и прочий COM я даже не брал в расчет

и зря .. одноэсный плагин как раз и должен быть реализован как СОМ-сервер автоматизации, а для серверов автоматизации проблема явного менеджмента памятью при взаимодействии с контроллерами, как понимаешь, не существует, бо эти ф-ции берет на себя ОС.

> sniknik © (17.11.05 21:23) [12]

> где это он доступен?

Ну воровать-то на Руси-матушке пока еще не перестали..

Заходишь в Осла, делаешь запрос на поиск ресурсов по кл.слову, например, "1СV7" и имеешь не менее одной ссылки по интересующей тематике.. качаешь, изучаешь, пробуешь, чешешь репу и только потом делаешь вывод, надо ли тебе оно за 16 (или сколько-то там) зеленых американских президентов

> Leonid Troyanovsky

ну а если сабж не рассматривать как одноэсный плагин, то все равно придется офомлять свою ДЛЛ как олей-сервер, бо встроенный в одноэсину язык , как бы он ни был похож на VBA, не позволяет, если не ошибаюсь, использовать (статически либо динамически) подпрограммы, экспортируемые сторонними библиотечными модулями.

> Digitman © (18.11.05 08:33) [13]

> и зря .. одноэсный плагин как раз и должен быть реализован
> как СОМ-сервер автоматизации, а для серверов автоматизации
> проблема явного менеджмента памятью при взаимодействии с
> контроллерами, как понимаешь, не существует, бо эти ф-ции
> берет на себя ОС.

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

--
Regards, LVT.

> Leonid Troyanovsky © (18.11.05 09:06) [15]

> И это правильно

Конечно правильно !

На то OLE/COM и были придуманы, чтобы обеспечить унифицированность взаимодействия разношерстных программных модулей.

Мистика при получении результата из dll Найти похожие ветки