Давай, сам дрыхни, програмер )

Victoriacom
pBuff = Marshal.AllocHGlobal(len) - это что за зверь?

Обёртка над LocalAlloc. И не факт что этой библиотеке на самом деле нужна память выделенная таким образом, а не просто память из кучи выделяемая Heap* функциями, или тривиально самим фоксом, когда в декларации используется STRING [@]

Victoriacom
ret = AnvizNew.CChex_Update(anviz_handle, dev_idx, Type, pBuff, len);
Типы там такие
anviz_handle - System.IntPtr
dev_idx - int[] - когда раскрываю подробности, там стоит int[1] = 1. Что это, массив Integer'ов?

Надо смотреть класс-обёртку AnvizNew. Как они там передают в апи этот массив (если вообще массив передают). И если это таки обёртка над тем же "плоским" АПИ который ты используешь, а не просто дотнетовская реализация этой библиотеки (но наличие IntPtr всё же говорит в пользу того что это таки обёртка - нативному шарповскому коду эти IntPtr без надобности).

Victoriacom
nRet = CCHex_ClientConnect(phHandle, @cIp, pnPort) && cIp = "192.168.1.222"

Её декларацию и пример вызова в C# покажи - не уверен что они со строкой работают. @ тут скорее всего не нужна - вряд ли они в этой функции как-то менять будут переданную строку (если там таки строка) - а @ нужна лишь для того чтобы фокс забрал назад "изменённые данные из буфера".

Victoriacom
Я думаю, проблема в System.IntPtr

Это тривиально платформенно-независимый указатель. Чтобы в x64 системах был 64-битный адрес, а в 32-разрядных соотвественно 32-битный. Для фокса это тупо 32-битное число будет.

Victoriacom
Или в выделении памяти Marshal.AllocHGlobal(len).

Теоретически может быть разница (зачем то же они так прописали в дотнете - хотя это "больше букв"). Так память выделяют в весьма специфических (т.е. редких) случаях - для подавляющего большинства случаев прикладного применения память таки из кучи выделяют - оно быстроее и проще, журнал Здоровье MSDN прям так и пишет
Сделать "так же" не составляет труда - АПИ LocalAlloc с нужным флагом, чтобы не надо было ещё и LocalLock использовать. Мало чем отличается от HeapAlloc на самом деле. Ну и SYS(2600) чтобы в фоксе в эту память читать/писать из его переменных-строк.

of63
Формально ... должно сработать одинаково и при ...

Фактически тоже. В плоских АПИ фокс массивы "не умеет", никакие из их вариантов. Если нужен массив тех же int, то организуй сам его в памяти (сишный массив - просто последовательность подряд размещённых в памяти элементов - в данном случае 4-байтовых int-чисел), и передавай адрес этой самой памяти.
Вся хохма в том, что сишные массивы НЕ ХРАНЯТ нигде своего размера, и, соответственно, при передаче массива в функцию нет решительно никакого способа определить сколько в нём элементов - конечно же если не передать явно это количество дополнительным параметром.
Так что скорее всего китайцы тупо берут всегда лишь 1 элемент массива, а значит можно не особо заморачиваясь декларировать этот параметр (точнее их там два) как INTEGER @ и просто по ссылке нужное число и передавать (тоже не забывая @ в коде вызова). Это позволит избежать BINTOC, и кроме того, если АПИ таки меняет значение в этом параметре-массиве, позволяет без хлопот получить его обратно.

of63
Но в случае с DECLARE-функций это может быть и не так.

Не может Нема там массивов. А фоксовые массивы вообще ну очень сильно отличаются от большинства других массивов - что чисто-сишных, что COM/OLE массивов SAFEARRAY.

of63
Доб. И еще.Если убрать улитки в вызове CChex_Update(phHandle, @aDevIdx, @aType, @cBuffer, nLen), то "все сломается"?

При декларации этих параметров как STRING @ оно "частично сломается" - т.е. вызов пройдёт, но вот изменённые в функции данные (буфер) в фокс так и не вернутся. Но это особенность STRING-а, он всегда передаётся как адрес строки/байтов, а "собачка" лишь говорит о том надо ли обратно в фокс-строку копировать данные из буфера (который могла поменять апи функция). Для INTEGER и прочих типов собачка уже меняет саму суть - передать в функцию "число" либо же "указатель на число", т.е. адрес памяти где это число хранится.

Ну вот, и теория подоспела.
Хотя ТС пока только убедился, что непонятная функция вообще работоспособна.

of63> Доб. И еще.Если убрать улитки в вызове CChex_Update(phHandle, @aDevIdx, @aType, @cBuffer, nLen), то "все сломается"?

ИК> При декларации этих параметров как STRING @ оно "частично сломается" - т.е. вызов пройдёт, но вот изменённые в функции данные (буфер) в фокс так и не вернутся. Но это особенность STRING-а, он всегда передаётся как адрес строки/байтов, а "собачка" лишь говорит о том надо ли обратно в фокс-строку копировать данные из буфера (который могла поменять апи функция). Для INTEGER и прочих типов собачка уже меняет саму суть - передать в функцию "число" либо же "указатель на число", т.е. адрес памяти где это число хранится.

На всякий случай повторю про собачку (улитку), что
а) собачка В DECLARE INTEGER действительно и естественно меняет ее суть: в API передается не значение, а ее адрес. С этим согласен, и с этим понятно
б) собачка в вызове заDECLAREрованной функции не меняет "сути": в API все равно будет передано значение. Поясняю в примере:

Да, так оно и есть. Вызов функции, это вызов функции, и в общем то не важно что за ней стоит - фоксовый код или АПИ. При декларации АПИ-функции просто создаётся невидимый "посредник", который с одной стороны выглядит как фоксовая функция, а с другой реализуется рантаймом как вызов некоторой внешней, "плоской dll функции". Хотя не то чтобы совсем уж невидимый, есть же LIST/DISPLAY DLLS и ADLLS()...

Где только вы все это находите.
Вроде функция - проще некуда, без собачек:



Исправлено 1 раз(а). Последнее : lulgu, 31.10.18 01:03