Системное арифметическое исключение: Delphi вызывает C # DLL через оболочку C ++ / CLI - PullRequest
Новая
       25

Системное арифметическое исключение: Delphi вызывает C # DLL через оболочку C ++ / CLI

2 голосов
/ 16 сентября 2009

У меня есть C # DLL, которая использует класс XslCompiledTransform для манипуляций с XML. Я украл оболочку C ++ / CLI для C # DLL.

При использовании Delphi 5 для реализации оболочки C ++ / CLI я получаю системную арифметическую ошибку. Вот объявление Delphi 5: 

procedure XsltMethod(XmlPath, XsltPath: PWideChar); cdecl; external 'ahma.dll';

Тело общедоступного метода C # создает новый объект XslCompiledTransform, и исключение появляется сразу же, когда только что созданный объект запускает свой метод load . Например: 

XslCompiledTransform xslt = new XslCompiledTransform();
xslt.Load(XsltFile);

Как упоминалось ранее, исключение, создаваемое из .NET DLL, является системным арифметическим исключением. Это происходит только при вызове из исполняемого файла Delphi.

Полагаю, я должен упомянуть, что метод load объекта снова работает нормально. Таким образом, перехват исключения и запуск метода для второго прохода действует как блокировщик всплывающих окон. Но, за исключением, конечно.

Ответы [ 2 ]

2 голосов
/ 17 сентября 2009

Возможно, вы страдаете от различий в регистре управления с плавающей запятой, как указано здесь . Также см. этот отчет о контроле качества. Вы можете попробовать позвонить Set8087CW ($ 133F); в вашей программе Delphi. Будьте осторожны с проблемами с плавающей точкой в ​​вашем Delphi-коде после этого.

2 голосов
/ 16 сентября 2009

Случайные мысли:

  • Я думаю, вам следует начать с отладки вашей сборки в Visual Studio. Вставьте окно сообщения или другой оператор ожидания в код Delphi, а затем присоедините к процессу из Visual Studio. Отслеживание C # может дать пару советов о том, что происходит не так. Если вы не можете заставить это работать, по крайней мере добавьте регистрацию входящих параметров.
  • В Delphi вам не нужно избегать обратной косой черты.
  • Вы уверены, что E0434F4D не является невинным исключением из первого шанса? Если вы не выполняете отладку (или продолжаете работу после остановки исключения отладчика JIT, что, как я не совсем уверен, возможно в Delphi 5), действительно ли поведение является ошибочным?
  • Можем ли мы ссылаться на "нативную сборку Win32" как на "DLL", как мы привыкли называть их в течение последних 20 лет? :-)
...