Для чего нужна функция SetUpdateCallback?

Спасибо, значит если я правильно понял, то:
1. SetUpdateCallback - приходят только изменения свечек
2.SetEmptyCallback -приходят 3000 последних свечек и в локальном терминале это пришедшие 3000 свечек - частично меняют те, которые уже были ранее?
А синхронизация свечей в таком случае идет по времени , привязанной к свече или у каждой свечи есть свой сквозной идентификатор ?

Спасибо за ответ, да нюансов много и как-то бы их надо понять, от этого наверно будет зависеть точность полученных данных. Что мне как новичку удалось понять из Вашего ответа:
1. Данные в терминал пользователя поступают в 2 потока, один поток это скоростной, для выполнения функций обратного вызова и SetUpdateCallback  и других функций и 2й поток main(), где работает код пользователя.
2. Данные, которые поступают через Первый поток ( название условное, используется просто для разделения о каком потоке речь), могут быть недоступны для кода пользователя во Втором потоке, этот вывод я сделал из Вашей фразы (неудобство - необходима аккуратная передача данных в скрипт(ы) Вашего робота (ов) (main))- что Вы хотели сказать этой фразой? Для того что бы данные передавать аккуратно, надо понимать что под этим подразумевалось?
3.С номерами свечей я примерно разобрался, если в цикле читать массив/таблицу полученных свечей, то где первый индекс, где последний становится примерно понятно.Или что вы имели в виду, что надо разбираться с индексами? Мне показалось, это обычный массив с данными.
4. Мне непонятно, что происходит с данными в терминале пользователя, если я допустим в 10 часов запустил робота для тестирования, он покрутился 10 минут и я его отключил. В результате в моем терминале скопились данные ( я работаю пока с минутным интервалом) 3000 свечей за 2 предыдущих дня и за текущий день до 10.10 включительно. Затем я включаю робота в 12 часов тоже на 10 минут и мне снова приходят данные и они перекрываются с теми данными, которые были получены в 10 часов, то есть новые 2 часа понятно это 120 свечей их не было на время с 10.10 до 12.10 с ними все ясно, а вот остальные свечи они каким образом объединяются с теми, которые были получены в 10 часов?  

Imho, Вы не с того начали.

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

Для начала Вам, как программисту, лучше было бы разобраться хотя бы по минимуму с архитектурой QUIK, после этого с архитектурой Вашего робота, обращая внимание на потоки, в которых будут выполняться его функции.
Какой-то минимум есть в документации (файл "Использование Lua в Рабочем месте QUIK.pdf").

Вы можете попробовать не использовать асинхронные выходы (callback), которые выполняются в специально выделенном так называемом "основном" потоке QUIK, ограничившись только потоками main (тут определенно есть злой умысел, main - можно перевести тоже как "основной"). Будет Ваш робот периодически просыпаться, пробегать по таблицам QUIK и Вашим собственным и принимать какие-то решения.

Захотите большей эффективности и сложности, задействуйте функции обратного вызова (callback'и). Одно дело, если в OnStop Вы просто взведете признак, который при очередном просыпании заметит Ваш поток main. Если в callback'е Вы получите более емкие данные (пока поток main спит по sleep() их может накопиться много) и захотите их накопить и передать роботу в поток main, то посмотрите потокобезопасные функции sinsert и sremove.  Разработчики иногда реагируют на замечания и закрывают очередную дыру в межпоточном взаимодействии, но они все равно остаются и лучше изначально строить робота так, чтобы он не бросал монетку - повезет - не повезет.

Определитесь с вариантом доступа к источнику данных, в частности, будете ли Вы работать только по закрытии текущей свечи или Вам важна ее динамика. Много вариантов есть: можно "монтекарлить" по срезам таблицы текущих торгов (OnParam - last) с риском пропустить экстремум, можно привязаться к графику по идентификатору, можно пропускать через себя все сделки (OnAllTrade), про варианты с CreateDataSource Вы уже знаете. У них у всех есть свои достоинства и недостатки, иногда даже опасности, свои временные характеристики.

Потом стоило бы смотреть на прикладную сторону - на торговые операции, получился бы движок робота. И только потом на его основе  реализовывать собственно Ваши стратегии.

На многие вопросы Вам придется отвечать самому, пишите и выполняйте Ваши программы, не бойтесь использовать отладочные выдачи по message или в файл, скорость отладки в LUA очень велика.  
Если Вы исследователь, то пробьетесь.

   

Вполне возможно, что Вам не хватит возможностей скрипта main и придется задействовать callback'и.

Термин "поток" я использую для обозначения архитектурной единицы ОС Windows, которая претендует на время процессора и другие ресурсы и может выполняться параллельно с аналогичными единицами. При определенных условиях они могут "подраться" за некоторые Ваши таблицы, которые Вы захотите ввести и обрабатывать (модифицировать) сразу в двух потоках. Для предотвращения таких коллизий (организация последовательного доступа) и были введены функции sinsert и sremove  (там еще несколько подобных по назначению есть, посмотрите).    
Не повезло QUIKу, многие термины перегружены разными смысловыми нагрузками, а некоторые объекты обзываются по-разному, это мешает.

В Вашем примере вы неявно находитесь в рамках потока main скрипта и имеете непосредственный доступ к данным источника, без задействования функций обратного вызова (те, что выполняются в основном ;) потоке).  

Зачем роботу графики - я не понимаю, Вы же сами все расчеты должны делать и чувствовать, где находятся Ваши кривые на текущий момент (втемную). Для визуализации или отладки можно использовать штатные графики QUIK и штатные МАшки, если Ваши с ними совпадают по алгоритмам. Если не совпадают - напишите для них свои индикаторы, это просто, и поместите их на нужные графики.

Для отслеживания и визуализации состояния робота постройте таблицу и отображайте ее средствами QUIK.    

Если нужны минимумы и максимумы за текущую торговую сессию, то их можно получить прямо из таблицы текущих торгов через параметры "LOW" и "HIGH". Примерно таким скриптом:А вот если нужны минимумы и максимумы за другие периоды внутри торговой сессии или между ними, то тут придётся уже мутить более сложный код с перебором всех значений по таблице всех сделок или по свечкам и пр.

Наверно зависит от того, с чем изначально вы работаете. Если вы работаете на свечках, то свечки и перебирать. А если на тиках, то таблицу обезличенных сделок. Оно просто по коду скрипта так будет получаться удобнее...

«Колбэки» нормально будут работать. Нахождение минимума и максимума простые мат. операции, просто два сравнения и присвоения, их прямо вовнутрь тела ф-ции OnAllTrade поместить и всё нормально будет.

Suntor, спасибо за объяснения, помогаете сориентироваться.

Код только начинаю писать, поэтому показать нечего. Пришла к следующему алгоритму:
При первом запуске скрипта,он перебирает последние тики/цены сделок до нахождения значений "текущая цена"+ х пунктов и "текущая цена"- х пунктов. Проверяет какое из значений было последним и присваивает соответственно 0 и 1 переменным "тренд вверх" и "тренд вниз", перебирает тики после значения "текущая цена" +/- х пунктов, находит и присваивает переменным "минимум", "максимум" значение или nil. Это только при запуске. Дальнейшее определение "тренда" и экстремума получается сравнением цены с его предыдущим значением.
С учетом упорядоченности цен в таблице и растущей индексации от старого к новому тику,
получается, что при получении каждого изменения, перебирать вообще не нужно. Или рациональнее для загрузки получать новые данные порциями и перебирать, зато реже обращаться к терминалу?
При наступлении события "текущая цена" -/+ х пунктов >/< мин./макс. меняется тренд и скрипт перетряхивает заявки, стоп-заявки. Они находятся на удалении от текущей цены, сильные движения редки (и вообще скрипт пишу в помощь рукам), поэтому опоздать с сигналом нестрашно. Но опять же вопрос, а нужна ли эта жертва или
получение каждого тика/сделки не больше грузит терминал, процесс?
Ещё скрипт снимает лимитки по ходу движения, ориентируясь на цену. В остальном, т.е. при работе с заявками оперирует таблицами заявок и стоп-заявок. Вот. И с ?
С чем ему работать? Откуда тут лучше брать цену, со свечь, тиков, тлиц обезличеннх селок?  

В общем, если бреда много, прошу простить, с Луа на этапе знакомства.

Почти написала и вернулась к обсуждавшемуся вопросу. Сейчас всё в main. Думаю задействовать OnAllTrade, но не вижу в нём смысла. Прошу развеять сомнения и поправить, если неправильно понимаю принцип работы.

Схема кода такая:Торгую si, т.е. сотни сделок в секунду случаются.

Допустим, задействовала я OnAllTrade. Посылает он сигнал main-у, а тот в это время находится где-нить в середине цикла. Что с ним будет?
Допустим, ничего. Тогда что будет с пропущенным сигналом OnAllTrade, потеряется?
Допустим, нет. Тогда за время проведения main-ом своих расчетов накопится много сигналов OnAllTrade. Что будет с ними? Будут обрабатываться в порядке очереди?
Ну и какой смысл в этом колбэке, если нет реакции на каждый тик? А main итак проверяет все новые тики.

тогда подумайте о том, что тики, пришедшие с биржи, попали к Вам не мгновенно в момент совершения сделки, а через время совершения события в ядре биржи, обработки в очередь на выдачу в буфере выходного потока ядра биржи, затем в буфер входного потока сервера АРКА, затем некая обработка на сервере АРКА, затем в буфер выходного потока с сервера, затем в буфер терминала для обработки в клиенте КВИК и вот уже это вы обрабатываете своим скриптом.
количество и скорость событий не являются ни линейными, ни предопределенными на всех этапах. так стоит ли переживать за такие мелочи? понимайте свой временной горизонт и перебирайте сделки по мере обработки и попадания в Ваши алчные алгоритмы :)

А зачем себя в хвост загонять, если разница в буквах кода? (Конкуренты в лице таких же юзеров QUIKа не в счет что ли и ликвидности не добавляют?)

В примере с колбэками из "Использование Lua в Рабочем месте QUIK" в main непрерывно проверяется размер таблицы Lua. А без колбэка мог бы также проверяться размер таблицы обезличенных сделок или иной. Чем хуже?

Тут вопрос не в том, хуже или нет. А в том, что код по другому структурирован. Можно в свою таблицу складывать события, а можно из системной их потом вылавливать. Тут есть свои плюсы и минусы. В том числе и с рассинхроном. См. мой пример в пред. сообщении.

Этот sleep относится к циклу fRun и нужен для того, чтобы скрипт не завис на бесконечном цикле. В этом случае его невозможно будет остановить кнопкой «Остановить» из окна скриптов. Да и весь Quik при этом также зависнит. Его можно ставить меньше по длительности или больше в зависимости от того, что вы в main делаете. Но он там должен быть обязательно.

На «колбэки» содержание кода в main никак не влияет, так как они исполняются в другом потоке.

На акциях, где нет «вечерки», тоже самое... это не про то речь. Quik если запустить через несколько дней, то он со старыми данными загрузится, они все в таблицах видны. А когда залогинетесь на сервер, то увидите, что все таблицы сбрасываются, а потом загружаются новыми последними данными. Вот в этом месте будет рассинхрон в работе скриптов. Нужно либо это в коде учитывать, либо ручками следить. Вообще, после некоторой практики приспособитесь к этому. В Quik'е вообще много похожих вещей, за которыми нужно либо самому следить, либо писать нетривиальный код их автоматизации.
Да не за что... )))

sleep в main и «колбэки» никак напрямую не связаны... разные вещи. sleep в main нужен для того, чтобы этот самый main не повесил весь Quik с концами...
main ничего не пропускает, а лишь реагирует с задержкой. И так он и должен работать, потому что ваш код изначально строится по схеме «опроса». И «колбэки» вы в эту схему засунули, чтобы лишний раз не дёргать getNumberOf, а я лишь довёл вашу эту схему до совершенства, грубо говоря, и вообще избавился от getNumberOf... Важно то, что вы строите ваш код по принципу опроса системной таблицы all_trades. Можно опрашивать её в main дёргая getNumberOf, сохраняя и сравнивая размер каждый раз, можно через булев флаг выставленный из «колбека» о том что таблица изменилась, а можно подсчётом событий «колбэков» насколько она изменилась, как в моём примере. В любом случае, этот код по схеме «опроса» будет работать с задержкой sleep в потоке main, и в любом случае эта задержка там необходима, иначе всё повиснет.
Он там есть, только спрятан в нижестоящую ф-цию ProcessingCallback... и это пример кода. Если в этом месте менять на свои реальные вычисления, то этот sleep нужно будет передвинуть выше в main. Можете все остальные примеры с первой и до последней страницы пересмотреть в этом документе, там везде в каждом main стоит sleep.
Ваше заблуждение лишь оттого, что вы через «колбэки» пытаетесь сделать код по схеме «опроса», где эти «колбэки» то и не нужны. Они нужны совсем для другого, кода вы строите код по схеме обратного вызова. То-есть, вместо цикла со sleep внутри main, где вы периодично опрашиваете таблицу, нужно поместить код в «колбэки», и он сам будет вызываться и именно в тот момент, когда наступит событие. А не тогда, когда цикл main после sleep наконец проснётся и обнаружит, что пока он спал, таблица all_trades приросла новыми данными. «Колбэки» срабатывают в тот момент, когда по сети информация приходит в Quik. Счёт идёт на миллисекунды... «Колбэки» это более мощное средство, и с его помощью можно имитировать схему «опроса», а вот наоборот уже не получится.

Все "глобальные" функции, кот. вызывает "колбэк", тоже выполняются в основном потоке терминала?