P.S. Правда адрес выдается IPv6, а хотелось бы IPv4.

var
  lData: array of byte;
.............
  SetLength(lData, 15);
  FillChar(lData[0], Length(lData), 0);
  fErrCode := GrdGetInfo(fGrdHandle, GrdGIR_RemoteIP, @lData[0], Length(lData));

В fErrCode возвращается код ошибки 46 (Недопустимые параметры при вызове функции). Попробовал различные варианты вызова GrdGetInfo:
GrdGIL_ID, GrdGIL_Remote, GrdGIR_VerSrv, GrdGIR_IniTimeOutSend - работают без ошибок.
GrdGIR_LocalIP, GrdGIR_RemoteIP - выдают ошибку 46.
Ключ находится на той-же машине, что и клиент, но подключаюсь как к удаленному ключу (GrdFMR_Remote вторым параметром GrdSetFindMode + GrdGetInfo(..., GrdGIL_Remote, ...) выдает что подключение сетевое).
Не подскажете в чем может быть проблема?

Правильно ли я понимаю, что память в буфере для возврата результата необходимо предварительно выделить (перед запуском GrdGetInfo)?

Да, все верно.

В pInfoData возвращается буфер, размер которого, для GrdGIR_RemoteIP, должен быть не менее 15 байт.

Антон, спасибо. Я в справке переключился на закладку С# (уже не помню зачем), а там информации о длине буфера нет, поэтому и возник вопрос.
Правильно ли я понимаю, что память в буфере для возврата результата необходимо предварительно выделить (перед запуском GrdGetInfo)?

Тут возникла необходимость получения адреса компьютера с сетевым ключом. Как я понимаю, для этого мы можем воспользоваться функцией GrdGetInfo с параметром GrdGIR_RemoteIP. Возникает вопрос: какого типа и длинны должен быть параметр infoData в этом случае? В идеале хотелось бы получить IP адрес в виде строки.

В pInfoData возвращается буфер, размер которого, для GrdGIR_RemoteIP, должен быть не менее 15 байт.

Тут возникла необходимость получения адреса компьютера с сетевым ключом. Как я понимаю, для этого мы можем воспользоваться функцией GrdGetInfo с параметром GrdGIR_RemoteIP. Возникает вопрос: какого типа и длинны должен быть параметр infoData в этом случае? В идеале хотелось бы получить IP адрес в виде строки.
При поиске по форуму нашел только такую тему (там кстати тоже просят возможность средствами API узнать количество занятых лицензий).

Судя по представленному описанию задачи, для ее решения, не видится препятствий при использовании возможностей таблицы лицензий (LMS), а именно модулей LMS.

Нужно в таблице лицензий целевого сетевого ключа создать необходимое количество модулей с различными сетевыми ресурсами для каждой версии защищенного приложения. Например, при необходимости разделить реальный сетевой ресурс электронного ключа (=10 лицензиям) на три версии защищенного приложения (v.1=5 лиц., v.2=2 лиц. и v.3=3 лиц.) нужно будет сформировать таблицу лицензий с общим ресурсом в 10 лиц. и тремя модулями (на 5, 2 и 3 лиц., соответственно). Каждому модулю назначается номер, который и потребуется указать при вызове функции GrdLogin , в качестве параметра dwModuleLMS. Таким образом приложение v.1 не сможет занять более 5 лиц., несмотря на реальный сетевой ресурс в 10 лиц., который также будут использовать еще и приложения v.2 и v.3.

Сейчас же при переходе на ключи Guardant хотелось бы обойтись минимальными изменениями, чтобы быстрее осуществить переход, поэтому менять нашу систему лицензирования мы не будем, по крайней мере на начальном этапе.

Первое с чем я столкнулся: в текущей реализации в памяти ключа прописывается реальный сетевой ресурс ключа (просто число в памяти), что дает возможность ограничить, например, сетевой ключ на 10 мест 7-ю лицензиями. При подключении к такому ключу математика считывает реальный ресурс ключа и получает через функцию API количество подключений (включая текущее). Если подключений больше - отключаемся с соответствующим сообщением (номер ключа/реальное кол-во лицензий). Это только "вершина айсберга" проверок дальше идут проверки по версиям и проектам.

В принципе обойтись без этой первой проверки можно. Достаточно при программировании ключа в таблицу лицензий ключа Guardant записать реальный сетевой ресурс ключа и подключения даже не произойдет (выдаваемое при этом сообщение я еще не видел, но уверен, что оно достаточно информативно для конечного пользователя). Сложность здесь заключается в прописывании этого самого реального сетевого ресурса - просто в определенное место дампа памяти ключа записать это число недостаточно, там еще нужно CRC посчитать и записать, как выяснилось. А сделать это нужно программно (у нас отдельная программа по программированию ключей совмещенная с нашей CRM системой). И еще надо научить утилиту дистанционного обновления ключа это делать. Т.е. ничего нерешаемого, просто дополнительная работа с тем чтобы в этом разобраться (изначально была идея сохранить дамп образа для ключей на 5, 10, 25, 50, 100, 250 мест и записывать дамп целиком в память, а "тонкое" ограничение оставить нашей математике, но без функции определения количества уже подключенных клиентов наша математика не сработает).

Прошу прощения, написал много, сумбурно, но в целом мысль такая: если такая функция появится в обозримом будущем, было бы неплохо, если же в планах этого нет - мы справимся и без этого, просто это будет дольше :-)

Нашел на форуме сообщение от 09.04.2013:

С тех пор ничего не изменилось? Не рассматривается ли возможность добавления в API такой функции (или она уже есть, а я ее не увидел)?

Спасибо.