Артем написал: Параметры работающие в реальном времени (такие как статус торговли) стали бы "обновляться" в момент вызова функции а не в момент фактического изменения.
Что бы это могло значить?
Артем, чем не устраивает предложенный мной вариант?
Надо делать так, как надо. А как не надо - делать не надо.
В результате текст во всех ячейках пропадает. Вернее окрашивается в цвет фона. Причём, после этого перекрашивание ячеек бесполезно - текст по-прежнему будет принимать цвет фона.
Надо делать так, как надо. А как не надо - делать не надо.
swerg написал: объективного понятия "загружены все данные" - просто нет. Ну в самом деле: на бирже изменилась цена
Не надо передёргивать. Я вам уже писал. Очевидно же, что когда говорят об "актуальности данных", речь про данные, которыми располагает сервер QUIK. Или для вас это не очевидно? Про ТТТ я писал в отдельной теме: важно понимать свежие ли значения мы имеем или это мусор, оставшийся со "вчерашнего вечера". Графики хранятся на сервере брокера, и при запросе клиентом архива графика, вместе с последней свечой, сервер должен отправить клиенту флаг "это всё, что есть сейчас". Для таблиц то же самое - нужен флаг об окончании загрузки.
Надо делать так, как надо. А как не надо - делать не надо.
swerg написал: Ну есть собатия прогрузки позиций после начал торгов / клирингов. И что они вам дают?
Именно об этом и спрашивает ТС.
Цитата
Nikolay написал: Первичные данные всегда актуальны на какой-то конкретный момент времени
Надо разделить 1) обезличенные данные и 2) данные, относящиеся непосредственно к портфелю: ордера, сделки, лимиты, позиции, стопы. Последние как раз будут статичны статичны и актуальны в начальный момент. Это и есть точка отсчёта, от которой будет отталкиваться скрипт. А тут про какую-то ТТТ начинают петь.
Надо делать так, как надо. А как не надо - делать не надо.
Павел написал: Не вижу проблем перед активацией опции сперва закрыть позиции, потом включить опцию автостоплосса.
У кого-то может быть другое мнение.
Цитата
Павел написал: Ну конечно, ориентация на исполненную заявку. Нет смысла, ставить стоп-заявку на 100 лотов, если забрало 50. Если вы поставили заявку и она исполнилась не вся, стоп-ставится на кол-во исполненной заявки, а неисполненный вы снимаете. Если не снимаете, и остаток все таки исполняется - стоп так же выставляется на кол-во исполненной заявки. На графике будет две линии стоп-заявки, и так же можно двигать ее куда надо.
Ну так исполниться она может не двумя, а ста сделками. Получите 100 стопов. Ну это опять же к вопросу удобства.
Вот и думают разработчики годами, как бы это так сделать, чтобы всем угодить
Надо делать так, как надо. А как не надо - делать не надо.
Отчасти соглашусь с разработчиками - задача не такая тривиальная, как может показаться на первый взгляд непосвящённому. Например:
Цитата
Павел написал: С этого момента все заявки вводимую в систему через режим Быстрого стоп-лосса начинают защищаться стоп-лоссом
Заявки или сделки? Если в заявке 100 лотов, и она исполняется частями по одному лоту, то когда и сколько должно быть выставлено стоп-заявок? А если заявка выставлена другим способом, из таблицы заявок, например, автостоп должен работать?
Цитата
Павел написал: Уже открытые позиции имеющиеся в системе до активации опции Быстрого-стоп лосса игнорируются. Иными словами, Активация опции + заполненные поля = работа алгоритма Быстрого стоп-лосса.
Допустим, до активации опции открыта позиция +2 лота. После активации опции и исполнении заявки на продажу 1 лота, какая должна быть выставлена стоп-заявка? И т.д и т.п.
Надо делать так, как надо. А как не надо - делать не надо.
Артем написал: Тут рекомендация докупить побольше оперативной памяти а не выжимать побольше возможностей из ограниченной системы. 32 гигабайта должно быть вполне адекватно
Надо делать так, как надо. А как не надо - делать не надо.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
1. При закрытии data_source память не освобождается, если был назначен SetUpdateCallback Код:
Скрытый текст
Код
local run = true
function OnStop()
run = nil
end
function main()
local function cb(index) end
local ds
while run do
ds = CreateDataSource(class, sec_code, INTERVAL_M1)
ds:SetUpdateCallback(cb)
sleep(500)
ds:Close()
ds = nil
collectgarbage("collect")
sleep(500)
end
collectgarbage("collect")
message(string.format("Memory: %.1f Mb", collectgarbage("count") / 1024))
end
Если убрать строку с SetUpdateCallback или заменить на SetEmptyCallback, память не растёт.
2. Если при загрузке модулей возникает ошибка, то библиотеки из памяти не выгружаются. Код:
Скрытый текст
Код
require(mod1)
require(mod2) -- Тут возникает ошибка загрузки модуля
-- mod1 выгружен не будет.
function main()
...
end
Надо делать так, как надо. А как не надо - делать не надо.
Проделал следующее: Сразу после первого сообщения об ошибке до закрытия свечи открыл минутный график. Через пару минут разорвал соединение с сервером. На свече объём 4984
Скрытый текст
Затем переключился на другой таймфрейм и обратно на минутный. Объём поменялся на 4982
Скрытый текст
Саппорт, вас интересуют баг-репорты?
Надо делать так, как надо. А как не надо - делать не надо.
Roman Azarov написал: Увеличение количества пользователей с пожеланиями об одном и том же конкретном функционале повышает его приоритет и вероятность его реализации в ближайшем будущем
Цитата
Alexey Ivannikov написал: по факту это выглядит так: сотрудник видит что пожелание "по делу" и заводит его, если пожеланий по одной теме накапливается всё больше и больше - это может изменить приоритет по ней.
Если я вижу, что пожелание уже зарегистрировано, достаточно "плюсануть" в открытой теме или надо заводить новую тему с аналогичным пожеланием?
Надо делать так, как надо. А как не надо - делать не надо.
Дабы предупредить спекуляции на другие темы: Обычно DataSource обновляются синхронно в порядке их создания. И, если нет разрывов соединения или потерь пакетов, это позволяет в тестовом скрипте сравнивать данные из DataSource разных таймфреймов.
Надо делать так, как надо. А как не надо - делать не надо.
Артем написал: Между чтениями данных из базы данных образуется задержка, которая может быть достаточно большой чтобы выполнилась одна или более транзакций.
Транзакция в прошлом? В окне сообщений есть и время свечи и время самого сообщения.
Цитата
Артем написал: Что именно он должен делать, если словами?
Показывать что
Цитата
Старатель написал: Иногда CreateDataSource возвращает неверные данные
Сравнивается дневной объём на D1 и M1. При несовпадении запоминается индекс крайней свечи M1 на момент создания DS (обычно эта свеча содержит ошибку). По закрытию свечи M1 выводится её содержимое. В message - одна и та же свеча из разных DataSource, открытых с небольшой (100 мс) временной разницей.
Надо делать так, как надо. А как не надо - делать не надо.
Иногда CreateDataSource возвращает неверные данные. Демонстрационный скрипт:
Скрытый текст
Код
class, sec_code = "SPBFUT", "SiH1"
local run = true
function OnStop()
run = nil
return 500
end
function main()
local Volume -- Дневной объём
local ds_D1 = assert(CreateDataSource(class, sec_code, INTERVAL_D1))
ds_D1:SetUpdateCallback(function (index)
if not run then return end
Volume = ds_D1:V(index)
end)
sleep(1000)
local Day = os.date("*t").day
local CreateDS = true
local ds_M1, Index
local function cb(index)
if not run then return end
if Index and index > Index then
run = false return -- Ждём закрытия свечи, на которой обнаружена ошибка
end
if math.floor(os.time() / 60) ~= math.floor(os.time(ds_M1:T(index)) / 60) then return end -- Время свечи не совпадает с текущим
local volume = 0 -- Суммарный объём за текущий день
for i = index, 1, -1 do
local day = ds_M1:T(i).day
if day < Day then break
elseif day == Day then
volume = volume + ds_M1:V(i)
end
end
if volume == Volume then
CreateDS = true -- Если ошибки нет, открываем новый DS
elseif Index == nil then
Index = index -- Если есть ошибка, запомним номер последней свечи
message(string.format("[ERROR] %s: index: %u: %s, %s", sec_code, Index, Volume, volume), 3)
end
end
while run do
if CreateDS then
if ds_M1 then
ds_M1:Close()
sleep(2000)
end
if run then
ds_M1 = assert(CreateDataSource(class, sec_code, INTERVAL_M1))
ds_M1:SetUpdateCallback(cb)
CreateDS = false
end
else sleep(1) end
end
ds_D1:Close()
if Index then
local function canle(ds, index)
local t = ds:T(index)
return string.format("%02u:%02u:%02u: %s; %s; %s; %s; %s", t.hour, t.min, t.sec, ds:O(index), ds:H(index), ds:L(index), ds:C(index), ds:V(index))
end
local s = string.format("%s: index: %u\n%s", sec_code, Index, canle(ds_M1, Index)) -- Выводим свечу, на которой обнаружена ошибка
ds_M1:Close()
sleep(100)
ds_M1 = assert(CreateDataSource(class, sec_code, INTERVAL_M1))
repeat sleep(1000) until ds_M1:Size() > Index
message(s .. "\n" .. canle(ds_M1, Index), 2) -- Сравниваем со свечой с тем же индексом из другого DS
end
ds_M1:Close()
end
Графики должны быть закрыты. Можно запустить несколько скриптов с разными инструментами. Через некоторое время будет сообщение вида:
Скрытый текст
Возможно, большое количество свечей повышает вероятность ошибки. Но это не точно.
Надо делать так, как надо. А как не надо - делать не надо.
Imersio Arrigo написал: если к примеру в графике 40тыщ свечей, а настройкамэ сделать "показывать последние 500", и нажать ок, то индикатор все равно щитаецо по 40тыщъ.
И памяти жрёт на все 40тыщ. Хотел ограничением кол-ва на тиковых графиках снизить потребляемую память - не вышло
Надо делать так, как надо. А как не надо - делать не надо.
И ещё: имею многолетний опыт общения с клиентской поддержкой и десятки отчётов о багах. Большинство из них (иногда после многонедельных или многомесячных препирательств со стороны "поддержки") всё же были признаны, некоторые даже исправлены. Но не помню ни одной проблемы, которая бы проявлялась при каких-то специфических настройках терминала или сервера.
Если я не прав, то путь сотрудник поддержки или вы (раз уж вы имеете утверждать мою неправоту) меня поправят: вот при таких-то настройках данная проблема вообще не проявляется.
Надо делать так, как надо. А как не надо - делать не надо.
swerg, я пишу отчёты о багах при дефолтных настройках терминала. А обсуждаемая здесь проблема проявляется, как при подключении к серверу брокера, так и в QUIK Junior. Так что никаких
Anton написал: Если есть хороший приток бидов, вас, возможно, закроют выше, но в этом случае и велик шанс, что это был локальный пичок с откатиком и по итогу цель протрейлить до максимума не достигнута, высадили. Собственно, так оно и будет происходить в большинстве случаев
Только в одном случае (<Цена последней сделки> - <спред>) мейкер решает, по какой цене вас высадить, а в другой (если бы была такая возможность: <Цена условия тейк-профит> - <отступ> - <спред>) - вы бы сами решали, по какой цене готовы сдать позицию.
Надо делать так, как надо. А как не надо - делать не надо.