Quikos_1 написал: type:string:1 //Таблица глобальных функций
Ну, если это таблица, то я сдаюсь и "умываю руки" :: . Похоже, вы долго будете развлекаться отладкой. Потом, просьба к вам, сообщить конечный результат в этой ветке.
Я некорректно написал - это строка которая помещается после вызова luaL_newlib(L, ls_lib); и до вызова функции "server_run", Вообщем не имеет значение что это. Оно всегда там находится внизу стек. Где таблица от CreateDataSource я указал.
Ну а вместе с руками и лицо можно "умыть" - так чтобы освежится и быть более внимательным. Конечного результата походу не будет, потому что это просто не работает, а тех поддержка не отвечает.
1) Ошибка: Оператор if (status_lua_pcall != 0) ловит только исключения. Функция . CreateDataSource обычно завершается, не выбрасывая исключение, даже если источник не создан. Надо анализировать результат выполнения CreateDataSource. Если источник не создан, то первое значение результата nil, а второй результат: строка описания ошибки создания источника. Похоже, вы запускаете свой скрипт в песочнице, а там класс для SBER не TQBR. У вас не создался источник свечей.
Далее мне смотреть не интересно.
Более того, вы не внимательны вдвойне - я четко написал, что колбек установленный при вызове SetUpdateCallback вызывается, а значит никаких ошибок при вызове CreateDataSiurce быть не может. Слишком уж вы не внимательны.
TGB написал: 1) Ошибка: Оператор if (status_lua_pcall != 0) ловит только исключения. Функция . CreateDataSource обычно завершается, не выбрасывая исключение, даже если источник не создан. Надо анализировать результат выполнения CreateDataSource. Если источник не создан, то первое значение результата nil, а второй результат: строка описания ошибки создания источника. Похоже, вы запускаете свой скрипт в песочнице, а там класс для SBER не TQBR. У вас не создался источник свечей. Далее мне смотреть не интересно.
Вы Невнимательны. И из за своего не внимания выделаете вывод, как будто бы это факт.
Посмотрите код из функции my_call_SetUpdateCallback, где я четко написал:
Код
ckeck_Lua_Stack(L_global);
//Проверяю что находится на данный момент в стеке Lua.
//Находится следующее:
----------------------------------------
Total element is stack:3
type:string:1 //Таблица глобальных функций
type:table: //Это как раз запрошенная таблица CreateDataSource
type:nil: //Ошибка при запросе таблицы CreateDataSource - то есть nil - ошибки нет.
----------------------------------------
И тогда не придется фантазировать на тему "Надо анализировать результат выполнения CreateDataSource."
Quikos_1 написал: Это так не работает, если только Вы монолог сами с собой не ведете.
Учел вашу критику :: .
1.
Цитата
Quikos_1 написал: Ох, Вы явно путаете сборку мусора оперативной памяти и рабочую структура стека Lua. Они ни как не связаны.
Сначала некоторое утверждение, а затем конкретный вопрос: 1) При уборке мусора просматриваются объекты скрипта и ищутся такие, на которые нет ссылок из среды выполнения скрипта. 2) Если в стеке скрипта, в момент работы мусорщика, находится ссылка на какую то таблицу и на нее нет других ссылок, то как мусорщик определит, что эта таблица «живая», не обрабатывая стек?
Я знаю это и поэтому и написал про глупость о сборщике мусора, который удаляет мою Рабочую таблицу из стека. Это рабочая таблица и они используется из колбекка, который указывается при вызове SetUpdateCallback - так что сборщик ни как может и не должен ее удалять. Неужели это не понятно.
Quikos_1 написал: ВОПРОС: КТО И ЗАЧЕМ очитстил стек ?? КАК видно из кода, между вызовов SetUpdateCallback и вызовом самой колбек-функции нет ни одной строчки кода, которая бы редактировала стек. Так что происходит тогда ?
Сами найти не можете?
Вы уже задали достаточно вопросов, но не ответили не на один мой. Это так не работает, если только Вы монолог сами с собой не ведете. Давайте еще раз: А Вы сами найти не в состоянии ?
Видимо Вы просто не разу не пытались заказывать данные по инстурменту, который у Вас не открыт в Квике.
Нормальный терминал - это тот, где нет ни одного графика, может только таблицы, для оценки взглядом цифр. Все делает сам скрипт. Так что это нормальная практика - заказать данные, рассчитать все данные, принять решения. SetUpdateCallback - очень неудобный колбек с точки зрения использования.
Во-первых, он вызывается на каждое изменение цены, даже внутри одного и того же бара. Если это необходимо отслеживать, то есть более удобные способы. А если не надо, то проще самому обрабатывать данные, реагировать только если Size потока изменился. Во-вторых, после заказа данных, он будет вызван для всех баров, начиная от 1. И опять - это проще сделать самому, перебрав данные в цикле. Ну и, наконец, - он медленный.
Впрочем, дело вкуса, конечно.
SetUpdateCallback - вполне себе удобный, только перестал работать для Си.
Про тот способ, который вы пишите про отличный от ""SetUpdateCallback" - нужно самому формировать интервалы из тиков, я побывал, но в итоге отказался от этого. Насчет того, что он будет вызван для всех исторических баров - это тоже не проблема, я просто пропускаю все исторические бары и смотрю только с того вызова колбека, который идет уже после последнего исторического бара.
Тут проблем нет - это все работало, это все уже было написано на С++. Но это просто перестало работать из за описанной мной проблемы. :(
Quikos_1 написал: ВОПРОС: КТО И ЗАЧЕМ очитстил стек ?? КАК видно из кода, между вызовов SetUpdateCallback и вызовом самой колбек-функции нет ни одной строчки кода, которая бы редактировала стек. Так что происходит тогда ?
1. На форуме много раз отмечалось, что если нужен результат, а не развлечение отладкой, то писать скрипты надо просто. Что-то использовать кроме QLua, надо в крайнем случае (в том числе C-API), если, действительно, QLua и многочисленных пакетов Lua не хватает для реализации задуманного. 2. Зачем вы используете C-AP? Что вам не хватает в Qlua? 3. В Qlua, как известно, автоматическая память и сборка мусора может быть запущена как внутри вызова C-API, так и при вызове коллбека, в основном отдельном параллельном потоке QUIK. Мусорщик работает по всем таблицам и стекам lua_State и что-то там делает.
Для примера: обычным скриптом вы не можете вызвать SetUpdateCallback - ЕСЛИ у вас не открыт график. Соответсвенно если вы хотите вызвать SetUpdateCallback для одного и того же инструмента но с разными временными интервалами, вам нужно их открыть на графике. Соответвенно, если выхотите ообратится к индикаторам - васм ОПЯТЬ нужно настроить их на графике. Это просто знатная * вам скажу.
Quikos_1 написал: ВОПРОС: КТО И ЗАЧЕМ очитстил стек ?? КАК видно из кода, между вызовов SetUpdateCallback и вызовом самой колбек-функции нет ни одной строчки кода, которая бы редактировала стек. Так что происходит тогда ?
1. На форуме много раз отмечалось, что если нужен результат, а не развлечение отладкой, то писать скрипты надо просто. Что-то использовать кроме QLua, надо в крайнем случае (в том числе C-API), если, действительно, QLua и многочисленных пакетов Lua не хватает для реализации задуманного. 2. Зачем вы используете C-AP? Что вам не хватает в Qlua? 3. В Qlua, как известно, автоматическая память и сборка мусора может быть запущена как внутри вызова C-API, так и при вызове коллбека, в основном отдельном параллельном потоке QUIK. Мусорщик работает по всем таблицам и стекам lua_State и что-то там делает.
Зачем вы спрашиваете почему я использую Lua C API и зачем пишите про сборщик мусора ?? Как это все отвечает на мой вопрос или проблему ?
Я точно знаю, что у меня работало. Может это быть из за перехода от USB-ключа, к двухфакторной аутентификации по смс и паролю ?? Я не вижу никаких других причин. Я тупо не понимаю че происходит, потому что у меня 100% работало.
nikolz написал: все верно, в стеке ее нет, так как колбек вызывает QUIK . А в момент вызова в стеке может быть все что угодно - т е то что делает VMLua в данный момент. При выходе из функции стек всегда очищается. Надо иначе передавать таблицу.
А как тогда можно передать таблицу ? Я же не могу ее куда то скопировать. Я должен же работать со стеком Lua, причем с тем стеком, который первоначально создал Quik.
Я покажу Вам фрагмент моего скрипта. Подробно объяснять лень. Но из собственного опыта могу сказать что для тиков это плохая затея. Тормоз ужасный. Кроме того тиков есть уже колбек OnAllTrade и лучше него вы не сделаете. У меня есть различные варианты, вот один из фрагментов:
Код
while d = = nil and k > 0 do d,err = CreateDataSource (clas,sec,m); sleep ( 1 ); k = k - 1 ; end
if d then --d[1]=sec; d[2]=clas; d[3]=ts; d[3]=tc; d[4]=m; d[1]
-- if m>0 then d:SetUpdateCallback(function(index) cbCandle(index,d);end);
-- else
d[ 1 ] = 0 ; d: SetEmptyCallback () ;
-- end
ds[j] = d;
end
ds[ 0 ] = j;
Спасибо. Но вы используете обычный Lua, с обычным Lua проблем то нет. Проблемы именно с LUA C API.
nikolz написал: все верно, в стеке ее нет, так как колбек вызывает QUIK . А в момент вызова в стеке может быть все что угодно - т е то что делает VMLua в данный момент. При выходе из функции стек всегда очищается. Надо иначе передавать таблицу.
А как тогда можно передать таблицу ? Я же не могу ее куда то скопировать. Я должен же работать со стеком Lua, причем с тем стеком, который первоначально создал Quik.
Слезно прошу помощи, я что то не вьезжаю, что происходит. Раньше вроде все работало, сейчас, как будто бы перестало.
Использую LUA C API - для вызова SetUpdateCallback, вот такой просто С++ код: да понимаю, что вероятность, что кто-то будет смтреть код стремится к нулю, поэтому срезюмирую поведение кода:
С помощью QLua C API:
-1:Я вызываю CreteDataSorce: вызов происходит успешно, мне возвращается таблица и нулевая ошибка. -2:Я подтверждаю это проверкой стека Lua: на вершине стека находится таблица и нулевая ошибка.
-3:Затем я вызываю SetUpdateCallback и передаю вв него саму колбек функцию, которая будет вызыватся при каждой совершенной сделке. Так же дополнительно я связываю по типу лямбды любое значение, чтбы предать для последующего ивзлечения его в самом колбеке.
-4:Вызыва SetUpdateCallback, убеждаюсь, что вызов SetUpdateCallback прошел успешно и опять проверяю стек на наличие ранее заказанной таблицы CreateDataSource - ОНИ НА МЕСТЕ! . -5: И наконец на рынке совершается сделка по заказанному инстурменту и вызывается колбек "my_callback__for__SetUpdateCallback". Все что я делаю в данном примере в этом колбеке это проверяю наличие моей таблицы CrateDataSourc в стеке Lua. ИИИИИИ ее там нет!!!! Весь стека кромер первого элемента был "кем-то" очищен!
ВОПРОС: КТО И ЗАЧЕМ очитстил стек ?? КАК видно из кода, между вызовов SetUpdateCallback и вызовом самой колбек-функции нет ни одной строчки кода, которая бы редактировала стек. Так что происходит тогда ?
Код
lua_State* L_global;
int static nummer_table_from_stack;
Код
void SetUpdateCallcak_wrapper(lua_State* L)
{
L_global = L;
std::cout << "L_global_adress:" << &L_global << std::endl;
//-----------------------------------------------------------------1-Вызовем функцию CreateDataSource:Начало--------------------------------------------
lua_getglobal(L, "CreateDataSource");
lua_pushstring(L, "TQBR"); //Добавим первый параметр функции CreateDataSource на вершину стека
lua_pushstring(L, "SBER"); //Добавим второй параметр функции CreateDataSource на вершину стека
lua_pushnumber(L, 1); //Добавим третий параметр функции CreateDataSource на вершину стека
int status_lua_pcall = lua_pcall(L, 3, 2, 0); //Так как все необходимые параметры добавлены в стек, то вызываем функцию lua_pcall - которая использя доабвенные параметры в правильном порядке - реализует вызов функции CreateDataSource: 2-ой параметр - это число аргументов, которые мы добаили в стек и которая принимает функция CreateDataSource; 2-ой: параметр - это число параметров, которое возвращает функция CreateDataSource. После успешного выполнения lua_pcall удаляет и значение функции и переданные аргменты со стека в кол-во указанном во втором параметре(не велючая функцию) и доабвляеи результат на стек в кол-во указанном во втором параметре.
//-----------------------------------------------------------------1-Вызовем функцию CreateDataSource:Конец--------------------------------------------
//-------------------------------------------------------------------5-Проверка на ошибку lua_pcall:Начало---------------------------------------------------------------------
if (status_lua_pcall != 0)
{
//Ошибка произошла при вызове функции lua_pcall при вызове CreateDataSource:
std::cout << "ERROR CreateDataSource" << std::endl;
return;
}
//-------------------------------------------------------------------5-Проверка на ошибку lua_pcall:Конец---------------------------------------------------------------------
else
{
nummer_table_from_stack = lua_gettop(L) - 1; //Это номер элемента в стеке L - в котором теперь размещается полученная от CreateDataSource таблица. "-1" - потому что CreateDataSource поместила на вершину стека две перменные: таблицу и переменную об ошибке. То есть таблица находить на предпоследнем месте с вершины стека.
my_call_SetUpdateCallback(L); //Вызываем SetUpdateCallback wrapper
}
}
Код
static void ckeck_Lua_Stack(lua_State* L)
{
std::cout << "----------------------------------------" << std::endl;
int top = lua_gettop(L);
std::cout << "Total element is stack:"<< top << std::endl;
for (int i = 1; i <= top; i++)
{
int type = lua_type(L, i);
const char* type_name = lua_typename(L, type);
std::cout << "type:" << type_name << ":";
if (type == LUA_TSTRING || type == LUA_TNUMBER)
{
std::cout << lua_tostring(L, i) << std::endl;
}
else
{
std::cout << std::endl;
}
}
std::cout << "----------------------------------------" << std::endl << std::endl;
//std::this_thread::sleep_for(std::chrono::milliseconds(100000));
}
Код
static int my_callback__for__SetUpdateCallback(lua_State* L)
{
//Значит произошла сделка!
std::cout << "Number_candle:"<< lua_tonumber(L, -1) << std::endl;
ckeck_Lua_Stack(L_global); //Проверяем стек Lua!!! И теперь в нем находится сдедующее:
----------------------------------------
Total element is stack:1 //Куда черт возьми делать моя ранее заказанная таблица CreateDataSource ?????
type:number:1
----------------------------------------
return 0;
}
Код
static void my_call_SetUpdateCallback(lua_State* L)
{
//--------------------------------------------------------
lua_getfield(L_global, nummer_table_from_stack, "SetUpdateCallback"); //"Извлекаем" из "таблицы" функцию SetUpdateCallback.
lua_pushvalue(L_global, nummer_table_from_stack); //Помещаем копию обьекта таблицы CreateDataSource на вершину стека.
//--------------------------------------------------------
lua_pushnumber(L_global, 555); //Просто для примера связываю какое то любое значение для передачи в колбек.
lua_pushcclosure(L_global, my_callback__for__SetUpdateCallback, 1); //Захватываем.
//--------------------------------------------------------
int status_lua_pcall = lua_pcall(L_global, 2, 0, 0); //Реализауем вызов функции SetUpdateCallback с аргументом таблицы, которую поместили на вершину стека
//--------------------------------------------------------
if (status_lua_pcall != 0)
{
std::cout << "lua_pcall__ERROR" << std::endl;
return;
}
else
{
std::cout << "SetUpdateCallback Success Call" << std::endl;
ckeck_Lua_Stack(L_global); //Проверяю что находится на данный момент в стеке Lua.
//Находится следующее:
----------------------------------------
Total element is stack:3
type:string:1 //Таблица глобьальный функций
type:table: //Это как раз запрошенная таблица CreateDataSource
type:nil: //Ошибка при запросе таблицы CreateDataSource - то есть nil - ошибки нет.
----------------------------------------
return;
}
}
Nikolay написал: В теории да. Но меня прямо коробит (без обид) такая запись. Переменная ds глобальная, объявляется где-то там. В первом варианте анонимная функция хотя бы видит ее как up-value, а во втором - вся надежда на то, что она объявлена и инициализирована.
Хотя бы объявите переменную в самом начале кода.
Да рукожоп я. Я забыл зону видимости. Передал "ds" в колбек через замыкание.
Развейте пожалуйста мои сомнения насчет того, что Quik и в частности SetUpdateCallback() - опять работают, какбудто бы их написал через %опу, и что руки их %опы, растут, как раз таки у меня.
Использую такой простейший код для теста: просто вывожу последнюю цену сделки и обьем по последней минутной свече:
Код
function main()
local class_code = "TQBR" -- Код класса
local sec_code = "SBER" -- Код бумаги
ds = CreateDataSource(class_code, sec_code, INTERVAL_M1)
ds:SetUpdateCallback(function(index)
local last_price = ds:C(index)
local volume = ds:V(index) -- Получение объема по свече
message("Last Price of " .. sec_code .. ": " .. tostring(last_price) .. ", Volume: " .. tostring(volume)) -- Вывод цены и объема по свече
end)
while true do
sleep(1000)
end
end
Данный код исправно работает. НО, как только я вывожу код SetUpdateCallback в отдельный колбек, то ничего более не работает. Ошибок также в скрипте нет, но он не сообщает ни о каких измененениях, то есть колбек функция указанная в качестве параметра для SetUpdateCallback - тупо не вызывается при изменнеии цены:
Код
function updateCallback(index)
local last_price = ds:C(index)
local volume = ds:V(index) -- Получение объема по свече
message("Last Price of " .. sec_code .. ": " .. tostring(last_price) .. ", Volume: " .. tostring(volume)) -- Вывод цены и объема по свече
end
function main()
local class_code = "TQBR" -- Код класса
local sec_code = "SBER" -- Код бумаги
ds = CreateDataSource(class_code, sec_code, INTERVAL_M1)
ds:SetUpdateCallback(updateCallback)
while true do
sleep(1000)
end
end
Кто из нас рукожоп ? Я или разрабы Квика ? Надеюсь, что я.
Уточните, пожалуйста, что понимается под сбоем ДФА? Правильно понимаем, что в этот момент соединение с сервером не установлено? Есть ли возможность записать видео с воспроизведением эффекта?
Я бы записал видео, но этот эффект проявляется произвольно. В момент вызова CreateDataSource - подключения к серверу нет. Но это не мешает CreateDataSource - выдавать корректный результат. Но иногда бывает Квике появляется сообщение, что то типа "цепочка сертификатов обработана, но обработка прервана на стороне сервера".
Я не уверен гарантировано, что с эти связано, так как этот "эффект" проявляется не часто - отследить трудно.
Сркипт простой, это просто вызов CreateDataSource. Такое немного не ожидаемый результат CreateDataSource похое выдает, когда происходит "сбой" в двухфакторной аутентификации.
nikolz написал: Quikos_1 , Хочу пояснить, сжатие данных их тиков в свечи мы делаем не для того чтобы меньше передавать с сервера данных, а для того, чтобы делать прогноз движения рынка. ----------------------- Поэтому , если мощности компа хватает можете считать свечи сами из тиков, а если нет желания считать можно получать их с сервера биржи. ----------------- прикол лишь в том, что сервер на бирже раньше вас рассчитает свечи и пришлет их Вам.
Для анализа я использую свечи с интервалами. Но сами интервалы формирую из тиков. И когда я это делал, я руководствовался именно предположением о производительности, то есть, чтобы снизить поток по сути одни и тех же данных Инструмента, но по разным свечным интервалом, но теперь я задумался, а нужно ли мне было так делать и не переделать бы. Вот поэтому и решил уточнить.
nikolz написал: я тоже делал расчет свечей по таблицам обезличенных сделок. Для этой цели и чтобы тестировать запаздывание данных относительно времени сделок на бирже я синхронизирую компьютер с сервером точного времени , что обеспечивает погрешность относительно биржи в пределах 10 мs
Не понимаю зачем синхронизировать ? Если Вам приходит тик с конкретной датой и временем вплоть до секунды - просто складируейте его в минутную, трехминутную, 5-и мутную и так далее Свечу и все. Или я что то не правильно понимаю.
Кроме того, как вы решаете вопрос обнаружение попущенных интервалов, если у вас просто нет никаких тиков?
Сначала я загружаю в память свечи или с дика, то есть сохраненную историю или загружаю доступные на сервере через CreateDataSource, и после этого складирую пришедшие Тики в этот предварительно загруженный массив. Теоретически пропущенных интервалов быть не должно.
Но если свечи рассчитывать в терминале, то начало таймов надо привязывать к атомным часам, иначе у Вас будут разные свечи на разных терминалах для одних и тех же интервалов.
Вроде бы не должно так быть.
Я просто рассчитываю свечи именно таким образом. А дату и время беру из пришедшего Тика.
То на сервер при SetUpdateCallback - идет по сути только один запрос по интервалу - "INTERVAL_TICK", а уже пришедшая цена с датой раскидывается по интервалу силами Квика ?
Нет, на сервер идет запрос для каждого интервала, так как свечи формирует не терминал, а сервер. ------------------ Поток свечей на 1-2 порядка меньше, чем поток тиков.
А как поток свечей может быть меньше - да еще и на порядок, если, TICK он один, а интервалов свечей несколько ? Если я выбираю дневную свечу - это же не значит - что колбек по ней будет вызываться один раз в день ? Он же будет вызываться ровно столько - сколько же и Тиковый интервал.
Поясняю, следите за руками. Тик - это сделка. Свеча - это способ сжатия информации о сделках путем вычисления четырех индикаторов на заданном интервале времени. -------------------------------- Если текущая сделка изменила значение какого-либо индикатора, то сервер пошлет это значение терминалу. Предположим у нас тайм 1 час. 1 индикатор - это первый тик в текущем часе. - 1 значение на интервал. 2 индикатор - это максимальная цена сделки на текущем часе. Этот индикатор изменится лишь при превышении цены текущей сделки максимальной цены предыдущих. 3 индикатор -это минимальная цена сделки на текущем часе. 4 индикатор - это текущая цена сделки, если она отличается от цены предыдущей сделки. ================= Теперь рассмотрим случаи когда тики будут пропускаться без создания новых значений индикаторов. Вот некоторые из них. 1) Если в сделке участвует айсберг или большой пакет, то цена сделок не будет меняться, следовательно значения свечей тоже не меняются 2) Если сделки совершаются внутри тела текущей свечи, то изменяется лишь 1 индикатор при условии , что цена сделки меняется ================= В итоге количество значений в свечах всегда меньше, чем число сделок. ============== Вы можете это проверить сами. Для этого напишите вычисление свечей по тикам и посчитайте количество полученных данных.
Давайте упростим ситуацию и у нас не будет индикаторов, а только свечной график.
Как Вы и написали - Тик это сделка.
У свечи есть такой параметр, как цена закрытия, которая постоянно меняется при совершении сделки - то есть с каждым Тиком.
НО цена сделки может не меняться, то есть несколько сделка прошли по одной и той же цене, НО в и этом случае - есть параметр Volume, который увеличивается с каждым Тиком в не зависимости от цена Тика.
На основании этого я могу сделать вывод, что поток Тиков будет пропорционально в разы меньше заказанных интервалов свечей.
То на сервер при SetUpdateCallback - идет по сути только один запрос по интервалу - "INTERVAL_TICK", а уже пришедшая цена с датой раскидывается по интервалу силами Квика ?
Нет, на сервер идет запрос для каждого интервала, так как свечи формирует не терминал, а сервер. ------------------ Поток свечей на 1-2 порядка меньше, чем поток тиков.
А как поток свечей может быть меньше - да еще и на порядок, если, TICK он один, а интервалов свечей несколько ? Если я выбираю дневную свечу - это же не значит - что колбек по ней будет вызываться один раз в день ? Он же будет вызываться ровно столько - сколько же и Тиковый интервал.
То на сервер при SetUpdateCallback - идет по сути только один запрос по интервалу - "INTERVAL_TICK", а уже пришедшая цена с датой раскидывается по интервалу силами Квика ?
напоминает DDOS атаку на сервер QUIK. Могут и отключить нафиг.
Просто скриншот не удачно прикрепился, никаких атак :)
я имел ввиду Ваши интенсивные посылки my_ CreateDataSource __HISTORY__wrapper( "TQBR" ,"SBER", "INTERVAL_M1" ) это очевидно Ваша функция создание источника и так 200 раз и без пауз между посылками. --------------------- Так делают DDOS атаку. КУЧУ посылок в один порт чтобы сервер лег. Безусловно, Вы сервер брокера не положите, но все равно выглядит не комильфо.
Рекомендуете поставить небольшую задержку между вызовами ?
none2 написал: Добавлю, что крашится случайным образом (и не всегда), но в начале торговой сессии. Если файлы в папке archive всё таки обновились до вчерашних значений (после перезапуска quik), то больше не крашится.
У меня крашится тоже случайным образом, но зависимость от обновления archive - не заметил.
В моменте не наблюдаем описываемое Вами поведение, информация на графике отображается (см. скриншоты: М60, Н4). Обращались ли Вы по данному вопросу к Вашему брокеру? Также просьба приложить скриншот как именно отображается информация в настоящий момент на Вашей стороне и какую версию Рабочего места QUIK Вы используете.
Вот скриншоты:
к брокеру не обращался, так как не понял на чьей стороне проблем в итоге.
Похоже это ошибка Квика плавающая. ПРЯМО сейчас на момент - 08.02.2023 в 16:32 по москве - на графике Яндекс(TQBR:YNDX) не отображаются свечи - Часового и 4 часового интервалов. Причем это ошибка распространяется и на API: CreateDataSource - так же не получает данные по указанным интервалам.
Это очень плохо, так как нет возможности отслеживать параметры и даже просто заказать историю. В чем может быть дело ?