Незадача с GrdLogin

В разрабатываемом приложении начал приделывать работу с ключиком.
Весь код просто скопировал один в один из работающего.
И выяснилась странная вещь:
вызов GrdLogin( m_hGrd, dwModuleLMS, dwLoginFlags ); результат выдаёт нормальный, всё у него казалось бы хорошо,
но при этом после вызова меняются значения: m_hGrd превращается в NULL и m_dwRemoteMode == 0

Повторюсь, текст модулей на C++ один и тот же, но в одном приложении таких чудес не случается, а во втором - всегда...
Тестировал на XP x32 и Windows 7 x64

Re: Незадача с GrdLogin

Здравствуйте.

Виктор Блинов пишет:

В разрабатываемом приложении начал приделывать работу с ключиком.
Весь код просто скопировал один в один из работающего.
И выяснилась странная вещь:
вызов GrdLogin( m_hGrd, dwModuleLMS, dwLoginFlags ); результат выдаёт нормальный, всё у него казалось бы хорошо,
но при этом после вызова меняются значения: m_hGrd превращается в NULL и m_dwRemoteMode == 0

Повторюсь, текст модулей на C++ один и тот же, но в одном приложении таких чудес не случается, а во втором - всегда...
Тестировал на XP x32 и Windows 7 x64

Верно ли то, что при прочих равных условиях (версия операционной системы, версия Guardant API (какая версия API используется?) и т.д.), два абсолютно одинаковых приложения ведут себя по разному (описанным образом)?

Что за параметр (переменная) m_dwRemoteMode? В GrdLogin таких параметров нет (что видно и из Вашего описания тоже).

Воспроизводится ли указанная проблема на нашем стандартном примере для Guardant API ((все примеры можно найти в папке "Samples" установленного комплекта разработчика, директория по умолчанию: " %Program Files%\Guardant\Guardant 6\%Public Code%\Samples\"))?

Re: Незадача с GrdLogin

Верно ли то, что при прочих равных условиях (версия операционной системы, версия Guardant API (какая версия API используется?) и т.д.), два абсолютно одинаковых приложения ведут себя по разному (описанным образом)?

Да, именно так.

какая версия API используется?

Поставил за выходные 6.2 от декабря 2012 и GrdAPI32.lib и *.cpp и *.h

Теперь другая незадача...

    Mode = Local ? GrdFMR_Local : GrdFMR_Remote;
    int ret = InitDongle();
    if (ret != GrdE_OK)
        return ret;

    ret = GrdDongle.SetFindMode(Mode, 0, 0, 0, 0, 0, 0, GrdFMM_ALL, GrdFMI_ALL);

возвращает 48 - т.е. GrdE_InvalidHandle

Re: Незадача с GrdLogin

Виктор Блинов пишет:

возвращает 48 - т.е. GrdE_InvalidHandle

Ошибка GrdE_InvalidHandle, скорее всего, происходит из-за того, что в некоторых языках программирования, периодически уничтожаются неиспользуемые объекты и передвигаются используемые, для уплотнения памяти (т. н. garbage collecting). В результате, происходит передвижение хэндла в памяти, в то время как hGrd указывает на старую область памяти.

Для того чтобы избежать данной проблемы, необходимо первым параметром функции GrdCreateHandle указывать null. В таком случае функция сама выделит память для хэндла, и он попадет в неуправляемую область памяти, и не будет подвержен действию сборщика мусора.

(2013-05-13 16:37:46 отредактировано Виктор Блинов)

Re: Незадача с GrdLogin

Ошибка GrdE_InvalidHandle, скорее всего, происходит из-за того, что в некоторых языках программирования, периодически уничтожаются неиспользуемые объекты и передвигаются используемые, для уплотнения памяти (т. н. garbage collecting). В результате, происходит передвижение хэндла в памяти, в то время как hGrd указывает на старую область памяти.

Странно. Казалось бы, чистые "плюсы", unmanaged код... По крайней мере в этом модуле.

Для того чтобы избежать данной проблемы, необходимо первым параметром функции GrdCreateHandle указывать null.

Спасибо, помогло...

Хотя... Разница у приложений как раз в том, что "старое" практически полностью unmanaged, с небольшими вставками на C#, а "новое" - наоборот, пускалка (и бОльшая часть кода) на C# - т.е. managed и как раз для работы с ключиком пускается unmanaged кусочек.