Там ограничение по размеру ответа, нужно paging делать, т.е. несколько запросов + задержка минут 15

Cubigator, а вы пробовали подход с подпиской Subscribe_Level_II_Quotes? ИИ рекомендует так:

function main()
local class_code = «TQBR»
local sec_code = «SBER»

— Подписываемся на стакан для инструмента
Subscribe_Level_II_Quotes(class_code, sec_code)

message(«Подписка на стакан активирована для »… sec_code)

— Скрипт работает, ожидая обновления данных по стакану
while true do
sleep(1000) — Ожидаем
end

— Отписка (в реальной работе нужно сделать отписку перед завершением скрипта)
— Unsubscribe_Level_II_Quotes(class_code, sec_code)
end

function OnQuote(class_code, sec_code)
— Функция вызывается при каждом изменении в стакане
local order_book = getQuoteLevel2(class_code, sec_code)
if order_book then
— Обработка данных по стакану, например, вывод данных о лучшей заявке на покупку и продажу
message(«Bid Price: »… order_book.bid[1].price… ", Offer Price: "… order_book.offer[1].price)
end
end

Долбаёб у меня нет квика поэтому я могу только предполагать из за чего у тебя фуфела не работает. Я предположил а ты пишешь сумашедший/дебил. Попробуй так candles = getCandles(«SEC», 0, 100) для свечей. Для стакана если тебе не нравятся ответы чатгпт то вот здесь есть ответ как без ГУЯ получить стакан. --> «quik2dde.ru/viewtopic.php?id=419»
цитата:

Кто-то спрашивает:

Мне нужно получить стакан без открытия стакана в Квике.

Я так понял это три основные функции:

-OnQuote
-getQuoteLevel2
-Subscribe_Level_II_Quotes
...

Кто-то отвечает:

Subscribe_Level_II_Quotes как раз и требуется для того, чтобы получить стакан с помощью getQuoteLevel2 без открытия таблицы стакана.

— пример
— задаем класс инструмента и инструмент
CLASS=«TQBR»
SEC=«SBER»

— один раз подписываемся на стакан
if Subscribe_Level_II_Quotes(CLASS, SEC) then
message(«Quotes Subscribed», 1 )
else
message(«Quotes NOT Subscribed», 2)
end

— после подписки получаем стакан столько раз, сколько нужно
qt = getQuoteLevel2(CLASS, SEC)

— отписываемся от получения стакана
Unsubscribe_Level_II_Quotes(CLASS, SEC)

Поэтому вытащи говно из своей башки, прочитай почему не надо брать данные с ГУЯ(можешь в интернете полазить), но судя по всему у таких олигофренов как ты элементарные вещи даже в голове не помещаются из за того что там вместо мозга говно. Мне вот интересно почему всякие выблядки вроде тебя начинают писать дебил и т.п. я же тебе такого не писал первый, зачем грубить Вась?

вот ещё чатгпт накидал несколько причин для тебя дятла:

• Ненадежность: GUI — это визуальное представление данных, а не их источник. Данные в GUI могут быть:
  • Округлены или отображены с ограниченной точностью.
  • Фильтрованы или отображены частично, чтобы сделать их более удобными для просмотра.
  • Изменены пользователем (например, масштаб графика, выбор отображаемых элементов).
  • Изменены программно (например, изменения в представлении данных, переключение между режимами).
• Нестабильность: GUI — динамическая среда. Элементы GUI могут быть изменены пользователем или программно:
  • Пользователь может перетаскивать элементы, изменять их размер или скрывать/отображать.
  • Программа может автоматически изменять GUI (например, отрисовывать новые элементы, перестраивать структуру GUI).
• Сложность: Доступ к данным в GUI часто требует сложных манипуляций:
  • Необходимо использовать специальные функции для извлечения текстовых значений из GUI.
  • Необходимо учитывать динамичность GUI и программно отслеживать изменения в элементах GUI.
• Отсутствие гарантий: Нет гарантии, что данные, полученные с GUI, будут точными, современными или полными.
• Плохая практика: Чтение данных из GUI делает код:
  • Сложным, менее стабильным, менее читаемым и менее переносимым.
  • Менее устойчивым к изменениям в GUI.
  • Более сложным в обслуживании и отладке.

Лучшие практики:

• Получать данные из источника: Если данные доступны через API, базу данных или файлы, используйте эти источники вместо GUI.
• Использовать события: Если нужно отслеживать изменения в GUI, используйте события (например, события изменения текстового поля, события изменения масштаба графика).
• Разделять логику и представление: Старайтесь разделять логику программы и представление GUI. Это позволит упростить код и сделать его более переносимым.

Как я и писал до этого возможно что твоя проблема

… Там есть проблема именно на первой свечке ПОСЛЕ клиринга, данные какое-то время считать нельзя, и еще после клиринга иногда меняется количество свечек в графике, а это мега-критично, так как из-за пропущенных свечей может поменяться вся логика. И это тоже нужно учитывать...

связана что используешь квик/луа через жопу. Но понять это такому упоротому как ты это наверное не дано.

П.С.
чтобы рассуждать на тему дебилизма тебе следовало бы для начала почистить ту дичь которую ты постишь и уже потом смотреть в это направление.



Долбаёб.)

__rtx, 

Попробуйте вместо:
getCandlesByIndex(ID_Graph, 0, x-MaxPer-2, MaxPer+1)

использовать:
getCandlesByIndex(SEC, 0, 100)

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

Cubigator, 

… Попробуйте выполнить getCandlesByIndex без открытого графика или getQuoteLevel2(class_code, sec_code) без открытого в Quik стакана, тогда поймете что откуда берется...

чатгпт говорит что так можно получать без ГУЯ(проверить не могу т.к. у меня линукс, квик 5000 лет не пользовал, луа никогда вообще и т.д.):

— Задаем класс инструмента и инструмент
CLASS = «TQBR»
SEC = «SBER»

— Подписываемся на стакан
if Subscribe_Level_II_Quotes(CLASS, SEC) then
message(«Quotes Subscribed», 1)
end

— Получаем стакан
local qt = getQuoteLevel2(CLASS, SEC)

— Выводим информацию о стакане
if qt ~= nil then
print(«Ask:», qt.offer[1].price)
print(«Bid:», qt.bid[1].price)
end

— Получаем свечи
local candles = getCandlesByIndex(SEC, 0, 100) — Получаем данные о 100 первых свечах

— Выводим информацию о свечах
for i, candle in ipairs(candles) do
print(candle.time, candle.open, candle.high, candle.low, candle.close)
end

— Отписываемся от получения стакана
Unsubscribe_Level_II_Quotes(CLASS, SEC)

Возможно Ваша проблема возникает из-за Вашего говнокода:

… Там есть проблема именно на первой свечке ПОСЛЕ клиринга, данные какое-то время считать нельзя, и еще после клиринга иногда меняется количество свечек в графике, а это мега-критично, так как из-за пропущенных свечей может поменяться вся логика. И это тоже нужно учитывать...

Попробуйте вместо:
getCandlesByIndex(ID_Graph, 0, x-MaxPer-2, MaxPer+1)

использовать:
getCandlesByIndex(SEC, 0, 100)

Не удивлюсь если проблема возникает из-за того что Вы вместо обращения к бэкэнду обращаетесь к ГУЮ(указывая ID_Graph). ГУЙ обновляется асинхронно но асинхронность != консистентность(lanes/атомарные структуры данных/shared memory/volatile). В бэкэнде свечи должны быть на месте(с чем в ГУЕ могут возникать проблемы из-за потоков, частоты обновления ГУЯ, ядро легло спать не воткнув данные в ГУЙ а воткнёт когда встанет и т.п.). Поэтому когда Вы пишете на форуме и думаете что общаетесь с разработчиками, на самом деле Вы общаетесь с техподдержкой(в которой могут за небольшие деньги работать такие же кубигаторы как Вы) и уже от техподдержки летит весь шквал г@вна который говнокодеры сами и создают а потом пишут в квик что он тормозит и не все свечи выводит. Делайте с учётом таких моментов как «лучшие практики» и очень большой пласт потенциальных проблем просто не возникнет т.к. Вы с ним даже не будете соприкосаться. Пример одного из пунктов «лучших практик» не брать данные с ГУЯ, вместо ГУЯ брать с бэкэнда. Даже не понимая почему так а не иначе можно избежать множества потенциальных проблем. Для примера что за проблемы могут быть: бид аск очень часто у бота и в ГУЕ разный(чем активнее инструмент тем чаще это будет проявляться) это может проявляться даже если Вы данные берёте из бэкэнда но у Вас разные потоки(для этого придумано lanes/атомарные структуры данных/shared memory/volatile). Часто любители потоков удивляются почему у них стаканы кривые, одна из причин может быть то что я описал.

Quntag, верно. Но есть и универсальные. Первый три, QuantConnect, StockSharp, Backtrader. Причем первые два имеют свой SDK, который можно использовать напрямую из своих программ. Backtrader уже монолит.

Дмитрий Овчинников, 
Ну вот тем более, отчёт красивый, но бесполезен. 
У меня тоже всё началось с написания скрипта:)

Quntag, 

Они сделали очень красивый отчётик, который можно сформировать в терминале

На ЕБС он показывает дикую дичь, бесполезная вещь.

Единственная возможность MQL по экспорту — формирование csv со сделками. Этим только и пользуюсь. Но как только хочется что то большее то он мне не помогает. 

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

А в целом да, если вы программист, тогда надо делать свой велосипед. Можно применить бэкграунд ;)

Gambler , 
Ну вы же прочитали пост, и увидели, что я пользуюсь библиотекой «FinamPy», ссылка на которую есть у вас на сайте. И да, эта библиотека для конкретного брокера. Совсем универсального пока не нашёл. 

Дмитрий Овчинников,
Единственная возможность MQL по экспорту — формирование csv со сделками. Этим только и пользуюсь. Но как только хочется что то большее то он мне не помогает. 
У меня по одному символу торгуются и лонги и шорты. Покажи мне сделки за месяц на одном графике по двум направлениям? Не может. 
Покажи мне эквити с фактором восстановления, за год торговли? Нет. 
Отправь мне таблицу, где написано, сколько я заработал по дням, неделям, месяцам? Тоже нет. 

Они сделали очень красивый отчётик, который можно сформировать в терминале, но не дают вообще никаких возможностей напрямую работать котировками и отображать чего я хочу, и в целом не дают отображать графики, не относящиеся к OHLC. 

Не очень хочется называть это нытьём, в конце концов у вас оно своё, у меня своё. Но под свои задачи языка MQL мне маловато, а с необходимостью поиска костылей для теста захотелось работать с котировками самому. К тому же эффективность и скорость тестирования в МТ тоже вызывала вопросы — по крайней мере в моей стратегии за один прогон я могу сделать больше, чем МТ.

Quntag, 
да, экспирация конечно это черные дни рабского однообразного труда, я всегда чертыхаюсь. Зато дает ощущение «работы». 
Насчет шва не понял, в MQL есть все возможности по экспорту данных.
Тестирование наладил с небольшими нюансами. Точнее с большими нюансами, но, наверное, я к ним уже привык.
Про версию терминала для алго я давно ною, но кого это интересует в MQ? Им бы побольше рюшечек туда налепить, это стандартный путь любого ПО. Сервер у меня с большим запасом, так что это скорее просто нытье.

Cubigator, 

… Проблема отсутствия данных после клиринга, о которой вы говорите...

Проблема с внимательностью у Вас(я не писал ПОСЛЕ клиринга я писал ПОСЛЕ ЕГО НАЧАЛА), внимательно читайте что я писал и вдумывайтесь в то что написано:

Совет: проведите такой тест — включите квик и Ваших ботов, дождитесь клиринга и убедитесь что !!!--> ПОСЛЕ ЕГО НАЧАЛА <--!!! (дальше тоже внимательно)--> Вам не приходят данные(которые только добрались до Вас т.к. бот был сильно занят расчётами и тасканием данных с графиков). smart-lab.ru/blog/1076580.php#comment17454415

… Какой идиот будет, что-то считывать во время когда идет клиринг? Робот в это время на паузе...

Если в бота приходят данные и он не успевает их обрабатывать то будет копиться очередь, у меня приходили данные 3 минуты после начала клиринга, поэтому никто их не считывает они не успевают вовремя обработаться поэтому копятся. Именно это я написал Вам проверить но с внимательностью у Вас проблемы, поэтому так подробно расписал.

… данные какое-то время считать нельзя, и еще после клиринга иногда меняется количество свечек в графике, а это мега-критично, так как из-за пропущенных свечей может поменяться вся логика...

Так может это из-за того что надо их брать не с графика а из бэкэнда? Не думали об этом?

… Я так понимаю вы вообще великий теоретик, но с практикой беда. Попробуйте выполнить getCandlesByIndex без открытого графика или getQuoteLevel2(class_code, sec_code) без открытого в Quik стакана, тогда поймете что откуда берется...

Насчёт луа, да никогда не использовал. Спросил у чатгпт, он сказал что можно:

ChatGPT:
Убедитесь, что у вас есть права доступа к данным уровня 2 и что нужный инструмент выбран правильно. Также проверьте настройки вашего терминала, чтобы разрешить доступ к данным стакана без графика.

Я:
то есть для этого не нужен график?

ChatGPT:
Да, для получения данных стакана с помощью функции getQuoteLevel2 график не требуется. Вы можете вызывать эту функцию в своем скрипте без необходимости открывать график. Главное — убедиться, что у вас есть доступ к данным уровня 2 для выбранного инструмента.

так же Вам писал коллега:

… график не обязательно открывать, если создать источник данных из Луа. Он эквивалентно делает подписку на сервер. smart-lab.ru/blog/1076580.php#comment17454189

Именно так и должны использоваться данные а не те костыли которые(с большой долей вероятности) используете Вы. Возможно те проблемы о которых Вы пишете что типа разработчики не делают как надо и самому приходится… Возникают именно из-за того что Вы используете квик/луа через жо#у и Вам видимо все эти костыли по кайфу. Поэтому чтобы понимать как нужно работать с данными в квике не надо знать луа и т.п. надо просто понимать как с данными не принято работать и этого достаточно чтобы не городить говнокод и потом за#бывать разработчиков тупыми вопросами на форуме. Соревнуясь между собой у кого какая тема ляжет светлая или тёмная или любая какую не дай.

Ещё есть момент с путаницей в показаниях:

Gambler <osaengine.ru>:
… график не обязательно открывать, если создать источник данных из Луа. Он эквивалентно делает подписку на сервер.

Вы:
… Я знаю, но так проще, а значит стабильнее...

И мне пишете:
… Попробуйте выполнить getCandlesByIndex без открытого графика или getQuoteLevel2(class_code, sec_code) без открытого в Quik стакана, тогда поймете что откуда берется...

А как же:
… Я знаю, но так проще, а значит стабильнее...

Значит не знали когда писали?(я кстати об этом писал выше smart-lab.ru/blog/1076580.php#comment17454332)

… Особенно было смешно читать ваши рассуждения про черную тему в Quik.  Поверьте людям она намертво кладет Quik это проверенный факт.

Почитал форум там пишут что и светлая кладёт квик. Поэтому там скорее всего писатели кода так его пишут что в «какой цвет не покрась они её всё равно положат».))) Поэтому ситуация не очевида. Откуда разработчики квика знают что именно кладёт квик? Может там такие «ядрёные велосипедные связки, многопоточность и т.п.» что хорошо что квик тормозит а не взрывается.

__rtx, Вы читайте внимательнее. ПОСЛЕ, а не ВО ВРЕМЯ клиринга. Какой идиот будет, что-то считывать во время когда идет клиринг? Робот в это время на паузе. Там есть проблема именно на первой свечке ПОСЛЕ клиринга, данные какое-то время считать нельзя, и еще после клиринга иногда меняется количество свечек в графике, а это мега-критично, так как из-за пропущенных свечей может поменяться вся логика. И это тоже нужно учитывать.
Я так понимаю вы вообще великий теоретик, но с практикой беда. Попробуйте выполнить getCandlesByIndex без открытого графика или getQuoteLevel2(class_code, sec_code) без открытого в Quik стакана, тогда поймете что откуда берется. И перестанете писать о ваших домыслах, которые мало коррелируют с реальностью. Особенно было смешно читать ваши рассуждения про черную тему в Quik.  Поверьте людям она намертво кладет Quik это проверенный факт.

Cubigator, 

… И вот как раз этот извращенный до нельзя способ и подтвердит их неадекватность. А сделать это нормальным способом, о котором их годами просят пользователи они неспособны. Ваше пожелание зарегестрировано — идите на юг.

Я их понимаю т.к. пишу всё сам. Но мне намного легче т.к. у меня «кастомный кейс» а у них все рынки, все инструменты, биржа сделала новую фишку все сразу пишут квик где нам новая фишка и т.д. Я как-то хотел по криптовалюте посмотреть но там есть некоторое кол-во отличий которое меня «не вдохновило». Например одна из причин — числа с плавающей точкой, я их никогда не использовал т.к. всегда только фьючерсы и всегда(почти) только си а там даже объёмы с плавающей точкой. У меня заточено всё под микро(использовать мало памяти, ссылки/указатели чтобы влазить в L1 и т.п.) т.е. пришлось бы кое-что переписывать и я не стал заморачиваться. А у них так нельзя всё расписано по дням и всё такое.

… Иначе после аварийного перезапуска системы в Quik ни один нужный скрипт не запустится...

Так docker/docker-compose же есть. Пропишите и всё, там можете определить что после чего запускать, сколько ждать, сколько раз перезапускать, что проверять запущено или нет и всё такое.

Cubigator, 

… Проблема отсутствия данных после клиринга...

Это не проблема. Это то как должно быть. В клиринг данные не должны приходить т.к. клиринг идёт. Если бы они продолжали приходить то это бы означало что где-то происходит «неуспев» и нужно искать где и почему. Но если у Вас такого нет то значит всё ок.(у меня по молодости было 14:03 а данные всё идут это как бы намекало что когда торговал то не совсем в тех данных ставил ордера и неудивительно почему бот работает не так как хотелось бы, у меня была связка эксель + квик, поэтому ГУЙ и данные лучше разделять(т.е. брать из бэкэнда а на ГУЙ можно смотреть можно не смотреть это уже дело вкуса)).

… Даже автоматические перезагрузки сервера во время обновления системы или аварийные ситуации провайдера VDS которые иногда случаются, никак не могут остановить работу скрипта. Он все равно запустится, и даже если были пропущены некоторые действия скрипт самостоятельно все восстановит. Я иногда месяцами не трогаю ничего...

Ну это уже больше девопсовские штуки и они сильно не критичны. Их можно делать 100500 разными способами например докерами и т.п. Это всё не относится к «горячему пути» а вот брать данные с ГУЯ, лучше так не делать. Но Вы скорее всего так и не делаете т.к. getCandlesByIndex(ID_Graph, 0, x-MaxPer-2, MaxPer+1) с ГУЯ данные(скорее всего) не берёт он их берёт из бэкэнда луа именно из этого же места они отдаются ГУЮ какой-то где-то метод(в коде квика(не луа)) их забирает и отдаёт на отрисовку.

__rtx, Кто расскажет? Такие же кубигаторы как Вы?)))

Да, тысячи мух не могут ошибаться в определении одной известной субстанции. По поводу адекватности. Для примера задайте им на их форуме вопрос как открыть в графике Quik любой инструмент с истекшим сроком экспирации, например для тестирования стратегии. Сразу скажу, что технически такая возможность в Quik не предусмотрена. Хер вам, а не тесты, но она существует и они даже подскажут как это сделать. И вот как раз этот извращенный до нельзя способ и подтвердит их неадекватность. А сделать это нормальным способом, о котором их годами просят пользователи они неспособны. Ваше пожелание зарегестрировано — идите на юг.

Еще по поводу адекватности разработчиков при реализации автоматического перезапуска скриптов после перезагрузки терминала можно рассказать. Чтобы этого добиться, нужно сделать несколько идиотских действий. Нужно открыть терминал, запустить все нужные скрипты и… нужно закрыть терминал, а потом опять открыть. Только в этом случае Quik запомнит какие скрипты у него должны быть активными. Иначе после аварийного перезапуска системы в Quik ни один нужный скрипт не запустится.  И таких ситуаций еще вагон с тележкой. Адекватность это не про разработчиков Quik и не надо тут заливать. Латают дыры и подпирают костылями только при самые вопиющих проблемах.

__rtx, Зачем мне проводить этот тест если я его уже провожу полтора года ежедневно? Мои боты работают 24/7 без выходных и праздников, с остановкой только на обновление скриптов или на перегруз сервака. Проблема отсутствия данных после клиринга, о которой вы говорите была обнаружена и решена мною в первые дни после запуска первого бота, и это, кстати, никак не связано перезагруженностью ботов. После, больше не было ни одного сбоя. Даже автоматические перезагрузки сервера во время обновления системы или аварийные ситуации провайдера VDS которые иногда случаются, никак не могут остановить работу скрипта. Он все равно запустится, и даже если были пропущены некоторые действия скрипт самостоятельно все восстановит. Я иногда месяцами не трогаю ничего. Единственное слежу чтобы от скрипта раз в два часа в рабочее время поступали сообщения. Если их не будет, значит что-то не так, но пока все так.

Quntag, 

Хочется чтобы было что то полегче, визуальная часть мне перестаёт быть нужна. И тогда сразу требования к платформам (Windows) уходит, 

Сорри, этот ваш комметарий раньше не прочел.
Тогда вам действительно Квик никак не подходит. Кроме Transaq коннектора или его эквивалента ничего и не придумаешь. Зато, хошь Питон, хошь JS, хош под Винду, хошь под Линукс. Новый Питон3.13 оч шустрый стал, но под него еще не все либы подогнали.

Gambler , для Quntag точнее пожалуйста, там у вас собрано до фига всего.) Сходу не разберешься.)

Просто трейдер, я и не советую. Так и сказал — мне она не нравится.
А чего там еще есть под Квик? S#? — этот смотрел лет 10 назад, ниче не знаю.) Что еще? Разве только самому ДЛЛ писать.