Re: Преобразование кода из C в VFP9 | |
---|---|
of63 Сообщений: 25244 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
Давай, сам дрыхни, програмер )
|
Re: Преобразование кода из C в VFP9 | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Обёртка над LocalAlloc. И не факт что этой библиотеке на самом деле нужна память выделенная таким образом, а не просто память из кучи выделяемая Heap* функциями, или тривиально самим фоксом, когда в декларации используется STRING [@] Надо смотреть класс-обёртку AnvizNew. Как они там передают в апи этот массив (если вообще массив передают). И если это таки обёртка над тем же "плоским" АПИ который ты используешь, а не просто дотнетовская реализация этой библиотеки (но наличие IntPtr всё же говорит в пользу того что это таки обёртка - нативному шарповскому коду эти IntPtr без надобности). Её декларацию и пример вызова в C# покажи - не уверен что они со строкой работают. @ тут скорее всего не нужна - вряд ли они в этой функции как-то менять будут переданную строку (если там таки строка) - а @ нужна лишь для того чтобы фокс забрал назад "изменённые данные из буфера". Это тривиально платформенно-независимый указатель. Чтобы в x64 системах был 64-битный адрес, а в 32-разрядных соотвественно 32-битный. Для фокса это тупо 32-битное число будет. Теоретически может быть разница (зачем то же они так прописали в дотнете - хотя это "больше букв"). Так память выделяют в весьма специфических (т.е. редких) случаях - для подавляющего большинства случаев прикладного применения память таки из кучи выделяют - оно быстроее и проще, Сделать "так же" не составляет труда - АПИ LocalAlloc с нужным флагом, чтобы не надо было ещё и LocalLock использовать. Мало чем отличается от HeapAlloc на самом деле. Ну и SYS(2600) чтобы в фоксе в эту память читать/писать из его переменных-строк. ------------------ WBR, Igor |
Re: Преобразование кода из C в VFP9 | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Фактически тоже. В плоских АПИ фокс массивы "не умеет", никакие из их вариантов. Если нужен массив тех же int, то организуй сам его в памяти (сишный массив - просто последовательность подряд размещённых в памяти элементов - в данном случае 4-байтовых int-чисел), и передавай адрес этой самой памяти. Вся хохма в том, что сишные массивы НЕ ХРАНЯТ нигде своего размера, и, соответственно, при передаче массива в функцию нет решительно никакого способа определить сколько в нём элементов - конечно же если не передать явно это количество дополнительным параметром. Так что скорее всего китайцы тупо берут всегда лишь 1 элемент массива, а значит можно не особо заморачиваясь декларировать этот параметр (точнее их там два) как INTEGER @ и просто по ссылке нужное число и передавать (тоже не забывая @ в коде вызова). Это позволит избежать BINTOC, и кроме того, если АПИ таки меняет значение в этом параметре-массиве, позволяет без хлопот получить его обратно. Не может Нема там массивов. А фоксовые массивы вообще ну очень сильно отличаются от большинства других массивов - что чисто-сишных, что COM/OLE массивов SAFEARRAY. При декларации этих параметров как STRING @ оно "частично сломается" - т.е. вызов пройдёт, но вот изменённые в функции данные (буфер) в фокс так и не вернутся. Но это особенность STRING-а, он всегда передаётся как адрес строки/байтов, а "собачка" лишь говорит о том надо ли обратно в фокс-строку копировать данные из буфера (который могла поменять апи функция). Для INTEGER и прочих типов собачка уже меняет саму суть - передать в функцию "число" либо же "указатель на число", т.е. адрес памяти где это число хранится. ------------------ WBR, Igor |
Re: Преобразование кода из C в VFP9 | |
---|---|
lulgu Автор Сообщений: 1838 Дата регистрации: 30.11.2016 |
Ну вот, и теория подоспела.
Хотя ТС пока только убедился, что непонятная функция вообще работоспособна. |
Re: Преобразование кода из C в VFP9 | |
---|---|
of63 Сообщений: 25244 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
of63> Доб. И еще.Если убрать улитки в вызове CChex_Update(phHandle, @aDevIdx, @aType, @cBuffer, nLen), то "все сломается"?
ИК> При декларации этих параметров как STRING @ оно "частично сломается" - т.е. вызов пройдёт, но вот изменённые в функции данные (буфер) в фокс так и не вернутся. Но это особенность STRING-а, он всегда передаётся как адрес строки/байтов, а "собачка" лишь говорит о том надо ли обратно в фокс-строку копировать данные из буфера (который могла поменять апи функция). Для INTEGER и прочих типов собачка уже меняет саму суть - передать в функцию "число" либо же "указатель на число", т.е. адрес памяти где это число хранится. На всякий случай повторю про собачку (улитку), что а) собачка В DECLARE INTEGER действительно и естественно меняет ее суть: в API передается не значение, а ее адрес. С этим согласен, и с этим понятно б) собачка в вызове заDECLAREрованной функции не меняет "сути": в API все равно будет передано значение. Поясняю в примере:
|
Re: Преобразование кода из C в VFP9 | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Да, так оно и есть. Вызов функции, это вызов функции, и в общем то не важно что за ней стоит - фоксовый код или АПИ. При декларации АПИ-функции просто создаётся невидимый "посредник", который с одной стороны выглядит как фоксовая функция, а с другой реализуется рантаймом как вызов некоторой внешней, "плоской dll функции". Хотя не то чтобы совсем уж невидимый, есть же LIST/DISPLAY DLLS и ADLLS()...
------------------ WBR, Igor |
Re: Преобразование кода из C в VFP9 | |
---|---|
lulgu Автор Сообщений: 1838 Дата регистрации: 30.11.2016 |
Где только вы все это находите.
Вроде функция - проще некуда, без собачек:
Исправлено 1 раз(а). Последнее : lulgu, 31.10.18 01:03 |
© 2000-2024 Fox Club  |