nikolz написал: Динамические данные надо брать через getParamEx., а getParamEx вызывать при срабатывании onParam.При этом, чтобы не читать ненужное, надо в onParam поставить фильтр на торгуемые инструменты.
При срабатывании onParam вызывать именно getParamEx или всетаки getParamEx2 ?
Anton Belonogov написал: Функции возвращают аналогичные наборы данных, но getParamEx2 предназначена для использования совместно с функциями заказа/отказа от получения параметров Таблицы текущих торгов - ParamRequest и CancelParamRequest (см. более подробную
А если открыта ТТТ, значит ли это что ParamRequest однозначно не нужен и все равно- что getParamEx2 или getParamEx ?
nikolz написал: Функция getParamEx берет параметры из архива терминала. Это сравнительно медленно.У инструментов много неизменяемых параметров. Их лучше выбрать один раз и сохранить в таблице. Потом брать из этой таблице не используя getParamEx.
Т.е. "более" актуальные данные нужно брать через getParamEx2 во всех случаях, когда открыта ТТТ ? Или могут быть другие ситуации ?
1. У меня открыта таблица тек.торгов с нужными инструментами. Как правильно получать данные из нее getParamEx или getParamEx2 ? 2. Сработал колбэк OnParam. Также- как правильно - getParamEx или getParamEx2 ?
nikolz написал: А если Вы это не сделаете то и доступ к этой функции не получите из разных потоков.
Т.е. если два потока ОДНОвременно (без локов) вызовут getParamEx2 в Квике, то он нормально это обработает как два вызова, т.е. по очереди ? Или один проигнорируется ?
Win 10-64bit, Quik 9.7.1.10, моя dll откомпилирована под lua 5.4.2 - все работает. Но раньше мог, при необходимости, вывести консоль такой функцией на с++:
"Si - фьючерсный контракт на курс доллара США/ российского рубля, обращающийся на бирже РТС FORTS." Вот это описание (или подобное) можно получить из Quik ?
Вопрос такой - можно ли какой функцией из Quik получить текстовое описание "что такое" базовый актив Si для фьючерса и, соответственно, для самого SiZ2 ?
Есть своя dll к Quik, написанная год назад, Quik 9.7.1.10 и VS 2019. Помнится, в том году, для отладки подключался к процессу info.exe из VS 2019 спокойно и все видел. Сейчас пробую - не важно запущен ли с скрипт с подключением dll или нет, Quik выходит с кодом 0 (без ошибок) вообще без слов. Что то сломалось не пойму куда копать то ?
Перенес все в main, передаю стэйт как параметр для вызова функции quik и все равно если перехват OnParam подключен в dll,то подвешивает quik в непредсказуемые моменты. В режиме отладки отловил тут акцесс виолэйшн в lua53.dll. Если OnParam не перехватывать, то все идеально. Что же еще может быть тогда ?
Anton написал: Мне вот мысль пришла, а какой транспорт используется?
На стороне приложения просто SetEvent (именной, ранее созданный), на стороне quik - сервер с бесконечным WaitForMultipleObject, сработал, выполнил функцию quik, данные в общую память и ответил приложению, там соответственно WaitForSingleObject принял ответ, данные забрал и по новой. Сбой только при включении OnParam...
Anton написал: Если вдруг она уже захвачена и мейн из своего потока еще раз пытается захватить, будет рекурсивный захват, что ок, а если мейн держит секцию и ее пытается захватить другой поток, будет дедлок. Возможно, отсюда ноги растут.
Ну так пока не включен обработчик OnParam со своим стейтом, то все ок и за 1 сек. lua_call с этим global_lua_state успешно отрабатывает более 26 тыс.раз. Только включаю обработчика, то может зависнуть на 10 вызове, а может на 1000-м... Хотя стайты точно разные в main и в обработчике. Если в main стэйт уже пришел, то адрес его уже не меняется. Сейчас из main я его не трогаю он используется только из одного потока, типа моего эвент-сервера и все хорошо до подключения обработчика...Дедлока, по идее, не может быть !
Т.е. все команды шлются через global_lua_state полученный из main в момент запуска скрипта. И если убрать обработчика OnParam, то все работает, подключаю OnParam - начинает вешать quik, хотя там свой state должен быть...
Anton написал: WaitForMultipleObjects вполне может быть в мейне
Не ожидал. Я как раз отдельный поток выделил - типа сервер где обрабатывается WaitForMultipleObjects. А если все в main, думал что quik зависнет в ожидании... Но в обычном порядке state в main попадает только один раз при запуске скрипта, как я понимаю ? А в callback-ах не тот де самый state приходит ?
Anton написал: Если заводится свой поток в длл, который будет дергать луа, нужно, да, создать для него стейт через lua_newthread
А что, есть возможность без нового потока "дергать" lua_State ? Просто у меня общая dll и для связи с quik и для связи с моей прогой. И из своей проги просто отправлял команду в dll, где по WaitForMultipleObjects как раз через ранее сохраненный глобальный lua_State, dll отправляла команду в quik.
Anton написал: Именно. Не надо сохранять стейт в глобальную переменную, в каждом колбеке (включая мейн) надо использовать тот стейт, что в эту функцию передан.
А как тогда правильно самому функции quik вызывать ? lua_newthread ?
Разобрался, подвисало все иногда из-за включенной в dll обработке OnParam. Очевидно, в некоторые моменты происходит одновременные манипуляции со стэком в lua_State из-за чего и сбой. Тогда получается, что нужно в разных потоках обрабатывать свои команды и quik события ? Или еще какие варианты ?
Из своей dll вызываю в цикле запрос getSecurityInfo " lua_getglobal(global_lua_state, "getSecurityInfo"); lua_pushstring(global_lua_state, class_code); lua_pushstring(global_lua_state, sec_code);lua_call(global_lua_state, 2, 1); "
собственно, по всем тикерам в одном цикле. И сейчас вдруг, иногда, в непредсказуемые моменты подвисает lua_call и, соответственно, подвешивает и сам Quik. Версия 5.3.5. Этом у меня тут что-то напутано или что еще может быть - куда копать ?
Да нет конечно и все используемые функции зеленые. Все вопросики только внутри "веток" KERNEL32.DLL и USER32.DLL ну так они и в рабочей версии присутствуют. А внутри PYTHON39.DLL и QT6QMLD.DLL вопросики тоже только с виндовыми dll.
А что это за ucrtbase.dll и ms-api-xxx.dll - они к qt не относятся ? Разве не должны они из системной path браться сами ? Если dependancy walker-ом пройти по РАБОЧЕЙ версии dll (без qt), то он тоже выдает там кучу вопросиков по разным API-MS-*.DLL, но работает.
1_dll.lua - для Quik - нужно поставить правильный путь в единственной строке - выдает ошибку при загрузке. 2_py_demo.py - для Python - нужно поставить правильный путь в третьей строке - все работает
Сама dll загружается и работает в Quik если собрать ее закоментировав одну строку "QQmlPropertyMap tmp;". Ну, соответственно, там и вес меньше и файл только один
Есть своя dll все работает, только добавляю туда классы из QT - перестает грузится в Quik. Эта dll, когда собираешь ее с QT, сама требует доп. dll-ок и там аж 3 каталога ей нужно. Это все создается в папке с dll спец.утилитой от qt. И такая dll нормально грузится из других программ. В чем проблема у lua с ее package.loadlib? Не знает, как доп.файлы подтянуть или же вообще на это не способна и придется отдельную библиотеку только с qt писать а в lua грузить "чистую" dll без внешних зависимостей?