Egor Zaytsev написал: Можем предложить вариант сравнивать с параметром "время последней сделки". Если цена ноль, а время последней сделки есть, то да цена ноль, если нет, то цена отсутствует.
Я спрашивал о надёжном способе. Вы можете гарантировать, что параметры "цена последней сделки" и "время последней сделки" обновляются синхронно? Т.е., когда вы проверите "время последней сделки", и оно будет присутствовать, то в "цена последней сделки" будет значение котировки?
Надо делать так, как надо. А как не надо - делать не надо.
Вопрос к разработчикам: Вы можете предложить надёжный способ убедиться, что getParamEx даёт действительно последнюю цену инструмента, а не её отсутствие?
Надо делать так, как надо. А как не надо - делать не надо.
Но разработчики QUIK и тут накосячили, перепутав местами цвета. Так RGB(255, 0, 0) должен соответствовать числу 0xff0000, а по факту соответствует 0x0000ff Т.о., если подставлять число в HEX-формате получим совсем другой цвет. Можете прокомментировать данную ошибку?
Надо делать так, как надо. А как не надо - делать не надо.
Вы не одиноки. Аварийное закрытие QUIK происходит при нажатии на кнопки "Применить", затем "ОК" в окне Редактирования настроек индикатора, работающего с меткой.
Надо делать так, как надо. А как не надо - делать не надо.
Функция CreateDataSource никогда не возвращает ошибку, И это создаёт большие проблемы при разработке. В неё можно запихнуть любой мусор, и она скажет: "Всё отлично".
Sergey Gorokhov написал: Вы предлагаете по сути заказывать информацию, не заказывая информацию. Так нельзя. Если заказали информацию, то получили ее размер (через Size), если не заказали то ничего не получили.
Вы не правы. Я предлагаю возвращать корректную информацию. Если информацию с сервера не получили, то её размер не определён (nil). Проблема как раз в том, что в текущем виде ноль невозможно интерпретировать должным образом. В данном случае устроило бы решение в виде возврата честного нуля, тогда и только тогда, когда точно известно, что по бумаге нет сделок. Если сервер ещё ничего не прислал, то Size должен возвращать nil.
Цитата
Sergey Gorokhov написал: Если и делать что-то подобное, то вне ds, отдельной функцией, например через транзакции, тогда возможно исключить терминал.
Это уже ваше дело, как реализовывать. Главное, чтобы можно было однозначно понять, стоит ли ждать чарта по бумаге или нет.
Надо делать так, как надо. А как не надо - делать не надо.
sav 312 написал: Предлагаю добавить в настройки СМС-оповещений пункт "оповещения по всем сделкам".
Уйдут месяцы на изучение потенциально целесообразности, проверку на юридические аспекты, анализ на непротиворечивость... и годы на саму реализацию. Плюс, если дождётесь, брокер должен включить у себя сервис СМС-рассылки, скорее всего за плату.
Проще уже сейчас самому реализовать необходимый функционал на Lua.
Надо делать так, как надо. А как не надо - делать не надо.
Функция CreateDataSource никогда не возвращает ошибку, И это создаёт большие проблемы при разработке. В неё можно запихнуть любой мусор, и она скажет: "Всё отлично".
Антон Кыт. написал: всем пользователям QuikLUA был бы полезен метод датасорса ds:ServerSize() Его смысл в том, чтобы сразу узнать сколько всего баров данного таймфрейма имеется на сервере истории
Почему это пожелание проигнорировано? Поддерживаю его. Возможные возвращаемые значения: натуральное число - количество свечей на сервере истории; 0 - история по заказанному инструменту на сервере отсутствует; nil - информация о количестве свечей на сервере ещё не доступна.
Т.о., если использование цикла ожидания
Код
while ds:Size() == 0 then
небезопасно и может привести к бесконечному ожиданию, то цикл
Код
while ds:ServerSize() == nil then
в этом смысле безопасен.
Надо делать так, как надо. А как не надо - делать не надо.
philave написал: В итоге после пересылки кода в поддержке QUIK воспроизвести падение не смогли, но предположили, что, скорее всего, проблема из-за того, что в скрипте для GUI используется IUP.
Знакомая песня. Поддержка всегда валит вину на кого-то другого, пока не "припрёшь их к стенке". Но из собственного опыта скажу, что у меня падения происходили чаще из-за ошибок в самом QLua.
Василий Петров написал: Обнаружил, что OnCalculate перебирает все свечи два раза, при этом общее количество свечей во вторую итерацию иногда меняется, иногда нет. Как такое поведение можно объяснить?
Цитата
Sergey Gorokhov написал: Что-то похожее уже чинилось, проверьте поведение на актуальной версии, сейчас доступна версия 7.7.
Цитата
Sergey Gorokhov написал: Проблема изучается. Постараемся в ближайшее время дать ответ.
Готового способа решения вашей задачи разработчиками не предусмотрено. Но с помощью встроенного языка Lua возможно сохранение / импорт меток. С линиями посложней. Но при желании и с этой задачей можно справиться. Но для этого надо изучать программирование на Lua.
Надо делать так, как надо. А как не надо - делать не надо.
Я не точно выразился. Конечно, порядок наложения как-то там влияет, но вот закономерность этого влияния мне установить не удалось. И после перезапуска Квика порядок обновления может быть уже совсем другим. У вас не так?
Надо делать так, как надо. А как не надо - делать не надо.
Вопрос не в том, что выводить - это зависит от индикатора, можно и вполне осмысленное значение. Вопрос в том, как выводить, если OnCalculate не вызывается?
Надо делать так, как надо. А как не надо - делать не надо.
Sergey Gorokhov написал: Он поведет себя ровно также как если бы был только 1 график, т.к. OnCalculate привязан к конкретному источнику данных.
Опять не совсем "ровно". OnCalculate будет вызываться при изменении источника данных, к которому привязан, но индекс свечи будет передаваться с учётом всех графиков на диаграмме.
Даже не знаю, хорошо это или плохо Допустим, нам надо построить индикатор по двум графикам. И на "ведущем" графике в какой-то промежуток времени отсутствуют сделки. Тогда мы физически не сможем построить индикатор, пока не получим следующую сделку. Есть лекарство?
Надо делать так, как надо. А как не надо - делать не надо.
_sk_ написал: Потом приходит следующая сделка, а она, как оказалось, относится к предыдущей 5-минутке. Будет ли вызвана функция OnCalculate() для FEES с предыдущим значением I? Если нет, то окажется, что свеча подменилась, а мы не в курсе. Если да, то это нарушение "обновления посередине".
Вопрос о том, как поведёт себя QUIK, когда по одному инструменту уже начал рисоваться новый бар, а по другому инструменту - вдруг приходит сделка по предыдущему бару? У меня есть подозрения, что Квику без разницы когда и что он получил. Он просто нарисует, то что пришло.
Надо делать так, как надо. А как не надо - делать не надо.
Sergey Gorokhov написал: В случае если в одном окне установить график по нелеквиду и по активному инструменту, Вы увидите что OnCalculate сработает по нелеквиду и CandleExist покажет false на пропущенных свечках только, после того как на нелеквиде появится нормальное значение.
Не совсем так. OnCalculate на пустых интервалах вызывается только при пересчёте индикатора (если, например, в окне редактирования нажать "Применить" или "ОК"). В реалтайм OnCalculate на пустых интервалах не вызывается.
Надо делать так, как надо. А как не надо - делать не надо.
_sk_ написал: Известно, что в данных об обезличенных сделках на фондовом и срочном рынке время задаётся разными часами, которые иногда могут разойтись на несколько миллисекунд.
Что значит "задаётся разными часами"?
Надо делать так, как надо. А как не надо - делать не надо.
funjpg написал: В такой ситуации, вопрос в сторону биржи, почему она присылает 0
Биржа тут не при чём. Это QUIK косячит: когда не может получить значение параметра (например, параметр не задан в списках) он подставляет туды 0 и говорит, что result="1"
Надо делать так, как надо. А как не надо - делать не надо.
swerg написал: ваша неправда в том, что в OnStop вы первым делом прерываете цикл в main. run = nil а после ошибочно утверждаете, что майн параллельно не работает.
Ваша неправда в том, что вы даже не проверили на то, о чём говорите. Можете переписать OnStop так:
Код
function OnStop(s)
Print('OnStop')
_sleep(3000) -- Здесь вы можете добавить некоторую работу, выполняющуюся на вашем компьютере определённое количество времени
Print('OnStop')
run = nil
return 5000
end
и убедиться, что в QUIK v.7 OnStop и main параллельно не работают.
Надо делать так, как надо. А как не надо - делать не надо.
Проверил: в v.6.16 потоки OnStop и main работали параллельно. В v.6.17 здесь уже внесли изменения. Возможно, сделано это было в благих целях: для корректной выгрузки библиотек или как-то так. Но об этом предупреждать же надо!
Надо делать так, как надо. А как не надо - делать не надо.
Nikolay Pavlov, Да, я ошибся в том, что отсчёт 5-секундного завершения скрипта всё же начинается по окончании OnStop.
Цитата
Nikolay Pavlov написал: Вы увидите, что после вызова OnStop() поток main продолжает работать
Ваша неправда: добавив в OnStop некоторые финализирующие действия, вы увидите, что пока они не будут выполнены, поток main не будет выполнять свою работу. А возобновит её после окончания работы OnStop.
Код
local run = true
local function Print(text)
PrintDbgStr(os.clock() .. ' ' .. text)
end
function main()
while run do
sleep(100)
Print('main')
end
sleep(4000)
Print('Quit')
end
function OnStop(s)
Print('OnStop')
run = nil
_sleep(3000) -- Здесь вы можете добавить некоторую работу, выполняющуюся на вашем компьютере определённое количество времени
Print('OnStop')
return 5000
end
Результат:
Цитата
31169.066 main 31169.167 main 31169.267 main 31169.368 main 31169.468 main 31169.569 main 31169.604 OnStop 31172.605 OnStop 31172.605 main 31176.607 Quit
Надо делать так, как надо. А как не надо - делать не надо.
Это верно, что во время работы колбэка OnStop работа потока main приостанавливается? Кроме того, скрипту даётся время на завершение работы, которое отсчитывается не по окончании OnStop (как это показано на вашей схеме), а от начала работы функции OnStop. Т.о., схема должна выглядеть так:
Скрытый текст
Надо делать так, как надо. А как не надо - делать не надо.
s_mike@rambler.ru написал: Упомянутый вами индикатор зигзаг также никогда не заглядывает в будущее, хотя перерисовывается на истории.
На истории Zig-zag рисуется уже с учётом будущих цен. Соответственно, и при тестировании на истории учитываются будущие цены. Это и есть заглядывание в будущее.
Надо делать так, как надо. А как не надо - делать не надо.
Предлагаю модифицировать функцию getDataSourceInfo: добавить необязательный параметр: STRING Tag и сделать функцию доступной как в индикаторах так и в обычных скриптах. При задании параметра функция будет возвращать параметры графика с идентификатором Tag.
Надо делать так, как надо. А как не надо - делать не надо.
Старатель написал: Sergey Gorokhov , если штатная функция при стандартной настройке ("С учетом настроек, выбранных пользователем вручную..." стандартная настройка?) работает некорректно, т.е., с ошибками, значит нужно исправлять эти ошибки.
Надо делать так, как надо. А как не надо - делать не надо.
Sergey Gorokhov, если штатная функция при стандартной настройке ("С учетом настроек, выбранных пользователем вручную..." стандартная настройка?) работает некорректно, т.е., с ошибками, значит нужно исправлять эти ошибки.
Надо делать так, как надо. А как не надо - делать не надо.
Добавьте, пожалуйста, для Lua-таблиц возможность работать в режиме связанных окон. Скажем, функцией SetLink(t_id, row, class_code, sec_code) устанавливаем, какой инструмент будет передаваться при выделении строки с номером row в связанные окна.
Надо делать так, как надо. А как не надо - делать не надо.