Индикаторы пересчитываются по каждому мовому данному, фактически по каждой сделке по инструменту. вы можете ограничить частоту расчета просто пропуская отдельные вызовы но лучше, конечно, написать индикатор так, чтобы он не тормозил
Однако вы правы про то, что выполнение main() прерывается на время OnStop(), как-то я вчера был невнимателен. Причем в самом деле: поведение изменилось между версиями 6.16.1 и 6.17.0
Хотелось бы услышать пояснения от разработчиков, такого изменения поведения не было заявлено, выходит это баг.
Ваша неправда: добавив в OnStop некоторые финализирующие действия, вы увидите, что пока они не будут выполнены, поток main не будет выполнять свою работу. А возобновит её после окончания работы OnStop.
ваша неправда в том, что в OnStop вы первым делом прерываете цикл в main. run = nil а после ошибочно утверждаете, что майн параллельно не работает.
вот здесь пример скрипта и подробные исследования откуда взялась ранее указанная мной схема
Анатолий написал: Совсем неожиданно образовалась еще одна проблема. Данная функция сработала до начала торговой сессии. В чем проблема? И как избежать таких срабатываний?
Приехали заявки/сделки, поданные вами в вечернюю сессию?
Уже веь написала подержка - с указанной проблемой обратиться к рокеру.
я же говорил о том, что для роботов стоит использовать брокера, у которого нет допонительной авторизации; и зависит это от брокера (настроек его сервера), а не терминала
ТС, работа нужно писать так, чтобы он корректно обрабатывал множественные срабатывания OnOrder хоть два, хоть три раза. и даже варианты, когда такого срабатывантя вовсе не произошло.
2016ый год на дворе. Сделайте уже кнопку "перевести срочные инструменты на следующий квартал", ну или как-то более ласково назовите ежеквартальную смену фьючерсов. на графиках, в таблицах текущих параметров и стаканах котировок
Если у Вас возникнут проблемы с освоением Lua поддержка всегда поможет.
Ау! Где вы любители великого и могучего клуа? И всегда на поддержке. Как пинать купайл так сразу, а как помочь...
Цитата
Но в QPILE нет сотен тысяч функций LUA
Ага, функция есть. Результата нет...
Дело в том, что вы не про QLua вовсе вопрос задаёте, а про то, как использовать Ami через COM-интерфейс, да еще через библиотеку luacom, которая сама по себе не сахар.
Предложение такое: приводить хотя бы рабочие (точно рабочие!!) примеры на любом другом языке для Ami, тогда еще, быть может, кто-то подскажет, как это переложить через вызовы luacom.
Без этого никто не полезет разбираться специально для вас в COM-модели Ami, потому как это очень непросто, если специально именно с этим не работать, а кому это надо.
Не вопрос. Просто функция main выполняется в отдельном потоке, т.е. она не мешает работе основного функционала терминала QUIK . Если скрипт маленький можно и без мэйн.
Дело не в том маленькая или нет. Для работы COM в потоке, в нем (в этом потоке) обязательно требуется вызвать CoInitialaize(), чего QUIK, конечно, не делает, т.к. ему это не зачем. Посмотрите подробнее здесь, там показано как COM-вызовы использовать в main() QLua https://quik2dde.ru/viewtopic.php?id=81
Так что есть предложение на этапе, пока вы это всё (в смысле связку с Ami) осваиваете, не трогать main(), потому как там свои нюансы.
Космонавт написал: 4. Она сработает, когда скрипт вылетит с ошибкой nil?
Нет. Напишется в обычном окне запуска скриптов.
Но на этапе загрузки скриптов индикаторов если в скрипте индикатора проблема - то информация об этом выдаётся именно через PrintDbgStr, т.е. при запущенном в момент загрузки индикатора DebugView вы ошибку в нем увидите.
Похожая проблема была исправлена в версии 7.6. Рекомендуем выбирать выражения при общении у нас на Форуме.
вы что же, приняли на свой счет? Так это к себе претензии возможно есть мотив обратить. я лишь выразил существенное удивление наличием похожей ошибки в финансовом софте и, более того, не предоставлением по этому поводу доступного всем патча. 7.6 не все могут использовать.
Космонавт написал: Вопрос 1. От понижения железа станут ли роботы медленнее реагировать на события? Колбек DataSourse, приход данных в стакан, колбек OnParam, колбек таблицы всех сделок? Вопрос 2. Стоит ли играться с настройками "Приоритет"? Это в диспетчере задач, где выставляется приоритет для процессов. Если да, то какому процессу давать повышенный приоритет: info.exe, winRos или обоим?
1. Все реакции на события в квике - в один поток обрабатываются, т.е. не одном ядре. второе нужно лишь чтобы система не мешала.
2. Все полезное выполняется только в info.exe winros лишь для експорта в метасток, этот файл вообще можно смело удалить. с точки зрения скорости реакции я думаю (но лишь из теоретических предпосылок) есть смысл поднять приоритет процессу инфо-ехе это должно давать ему приоритет при конкуренции за ядра прооцессора от иногда возникающих системных фоновых задач (другого же у вас нет,надеюсь?) хотя конкуренции у вас нет судя по загрузке, это хорошо. но не поднимайте до реал тайм! Сначала попробуйте на локальном компе, чтобы понять к чему это приводит.
Вообще было бы хорошо, если бы вы толком написали задачу, вы ведь как обычно толком не описываете, однак по сразу спрашивайте вопрос. если ваш колбек сложен и работает долго (длльше получения инфрмации из сети), то есть смысл разносить по разным копиям терминала, т.к. получите параллеьность если жи колбеки короткие и быстрые - то смысла разносить нет. чтоесть быстро и медленн - покажет лишь ксперимент в ваших условиях.
Космонавт написал: Поэтому я и пытаюсь получить не эмпирический ответ, а ответ на основе логики, теории и здравого смысла.
это ваша ошибка. Истину дают только экспериментальные данные, а никак не теория, теория лишь прдгоняется под эксперимент, всегда и везде.Космонавт написал: Так как опыты дают слишком разные результаты.
а вот это уже недостаток теоретических знаний по обработке результатов экспериментов.
поясню. Если вы хотите чтобы время выполнения заявки было не больше такого -то, то это одна постановка задачи. Если же вас устраивает, что в среднем время выполнения было какое-то, но при этом некоторые заявки выполнялись заметно дольше и это не критично для вашей задачи - то это совсем другая задача и подходы измерений и настроек другие.
исходя из задачи и требуется постановка экспериментов, тюнинг системы и анализ результатов.
Если нужна скорость - то нет совершенно никакого смысла теоретизировать. Только мониторинг, получение объективных результатов в вашем конкретном случае, выявление узких мест, оптимизация и снова мониторинг.
Цитата
Да, нужна быстрая реакция на события. При этом не хочется нагромождение из второго КВИКа или второй виртуалки.
Мы про хочется/не хочется или результат? вы уж определитесь. В любом случае нужны тексты в вашей конкретной инфраструктуре.
если речь про скорасть реакции на события - то два разных квика будут быстрее наверное. Потому что колбеки будут работать параллельно. А процессоры нынче все многоядерные. но ресурсов два квика будут есть побольше, чем один.
Нафик такого мутного брокера. Ибо он вас явно обманывает: очевидно ведь, что возможность торговли никак не зависит от платформы, через которую вы торгуете. Как вариант - он просто продвигает таким образом свою платформу. Ну либо вы его как-о не так поняли.