s_mike@rambler.ru написал: Свеча является закрытой тогда, когда появилась новая.
А не бывает такого, что приходит значение по предыдущей свече после прихода значений по новой?
бывает: 1) если это значение не было загружено ранее. 2) если это свеча индикатора, то так будет всегда для всех индикаторов, которые "заглядывают в будущее" - таких как fractal, ZigZag, и т д --------------------- Сама свеча цены - это тоже индикатор заглядывающий в будущее, поэтому закрытие свечи происходит лишь по истечению времени интервала, а не по времени последней сделки. ------------- В скрипте индикатора закрытие свечи определяется условием неравенства текущего индекса onCalculate предыдущему.
речь о нумерации свечей, а не о расчете значений индикаторов.
по п.1: ситуации, когда вдруг свечки на графике раздвигаются и между ними появляется ещё одна свеча, никогда не видел и не могу представить
s_mike@rambler.ru написал: Свеча является закрытой тогда, когда появилась новая.
А не бывает такого, что приходит значение по предыдущей свече после прихода значений по новой?
ни разу с таким не сталкивался.
проблемы подобного рода могут быть при считывании свечей с графика по идентификатору графика, когда на нем есть пустые диапазоны справа. Например при наличии других индикаторов, сдвинутых вправо.
но мы же рассматриваем простой случай, когда человек пишет для себя, а не а продакшен.
Александр Волфовиц написал: s_mike@rambler.ru, спасибо, действительно самый простой вариант.
Тогда такой вопрос: на дневном графике в ходе торговой сессии Size() указывает на свечу предыдущего дня, я правильно понял?
Size даёт число свечей, которые доступны.
таким образом, если сегодня торгов нет, то последняя свеча вчерашняя и Size() равна ее номеру. Если сегодня (сейчас) торги идут, то последняя свеча сегодняшняя.
local run = true
local tid = nil
local file
local gcrunner = ( function ()
local t = {}
setmetatable(t, { __gc = function ()
local t = tid
tid = nil
if t then DestroyTable (t) end
file:write( "__gc\n" )
file:close()
end })
return t
end )()
function OnInit (script_path)
file = io.open (script_path .. ".log" , "w" )
file:write( "OnInit\n" )
end
function main ()
file:write( "main\n" )
tid = AllocTable ()
AddColumn (tid, 1 , '1' , true , QTABLE_INT_TYPE, 1 )
CreateWindow (tid)
while run do sleep ( 300 ) end
file:write( "main stopped\n" )
end
function OnStop ()
run = nil
file:write( "OnStop\n" )
end
В логе:
Цитата
OnInit main OnStop main stopped
я может плохо смотрю, но не вижу вызова функции gcrunner
нет в базе данных терминала адреса строки или чего то ещё, описывающей сущность типа сделка, лимит или позиция по фьючерсам. Невозможно передать адрес этой сущности. Хранилище не есть примитивный массив, это база. Уж не говоря о безопасности.
нет в луа стандартных средств для прямого лазанья по памяти указателем.
квалификации разработчиков терминала вполне достаточно, чтобы правильно решать тривиальные вопросы типа "передать ссылку или значение", можете не сомневаться.
Выгоднее информацию из колбека сохранить в скрипте и оперировать в дальнейшем уже этой информацией
дело в том, что qlua - это пришлепка сбоку к терминалу, общающаяся с ним через тоненькую дырдочку. Поэтому любая операция получения информации из терминала в луа несёт значительно бОльшие затраты, чем оперирование этими же данными в самом скрипте.
только нужно иметь ввиду, что встроенные функции типа table.sinsert приемлемо работают при небольших размерах массивов, при увеличении размеров скажем до миллиона записей в нем начинается беда.
В общем случае колбек - это более грамотный способ. Если вы опрашиваете таблицу терминала на предмет получения новой записи и делаете это много раз в секунду, в большинстве случаев вы не получите факта изменений и будете гонять терминал впустую. Если же вы получили колбек и исходя из этого факта полезли в таблицу - это эта работа уже является полезной, а не бессмысленной.
GoldRat написал: Если в параметр индикатора на QLUA, описанный в таблице Settings, ввести значение 10000, он его меняет на 10. Почему? Версия Quik 8.8.4.3
рпзработчики считают, что параметры со значениями более 1000 вам не нужны. Откуда у них это знание, неизвестно.
используйте текстовый параметр и преобразуйте его значение в число.
Олег написал: Добрый день, хочу реализовать выход из всех позиций на открытии последней свечи дня для любого таймфрейма (торговля внутри дня) от 1М до 60М. Идеи как то не приходят в голову, на что можно опереться, чтобы работало независимо от выбранного таймфрейма.
DVN написал: Anton, спасибо за ссылочку! Второй вопрос остается открытым.
в общем и целом нельзя.
косвенно и очень приблизительно можно. В колбеке стакана анализируйте, по какому инструменту было изменение стакана и таким образом через некоторое время будет примерная цифра количества открытых стаканов, в которых есть жизнь.
конечно, если в инструменте жизни нет или не идут торги, ничего не узнаете.
s_mike@rambler.ru написал: Не используйте форум не по назначению (в рекламных целях, в целях личной переписки или в целях обмена информацией, прямо не связанной с QUIK, а также по другим неуместным поводам
Убрали ссылочку на Ваш сайт из подписи? Ну и хорошо. Как будто ничего и не было )
Цитата
s_mike@rambler.ru написал: по остальным ошибкам, перечисленными мной выше и о тех, что я забыл написать, вы точно также можете спросить у поиска по форуму.
Нет уж, ссылки с Вас. Про движение навстречу мы выше уже писали. И ничего "подтирать" из написанного ранее мы не будем, хотя это примерно тоже самое (по лёгкости) что и ссылку на Ваш сайт из подписи убрать. Приведите ссылки на не исправленные проблемы пятилетней и более давности (как Вы пишите) - и я обещаю лично заняться этими вопросами. Но не так что "Вы ищите - я где-то точно что-то такое писал". Надеюсь что мы поняли друг друга.
про ссылки я сначала не понял. Для меня ссылки - это ссылки в тексте сообщений. Про них я и ответил.
подпись - это мои дополнительные координаты. Скайп, сайт, телеграм. О том, что ссылками вы называете координаты в подписи, я догадался далеко не сразу, у вас особенная терминология. (Интересно, а что ещё в подписи профиля может быть на форуме?) Убрал. Если надо вернуть, верну.
P.S. Ремарка выше по поводу рекламы к Вам также относится.
Правило форума в этом вопросе:
Не используйте форум не по назначению (в рекламных целях, в целях личной переписки или в целях обмена информацией, прямо не связанной с QUIK, а также по другим неуместным поводам
все ссылки, которые когда либо были мной размещены здесь, были ответами на запросы иных пользователей по вопросам расширения функциональности терминала quik, написаны с использованием встроенного языка терминала quik, предназначены для использования совместно с терминалом quik либо в среде терминала quik, не являются личной перепиской либо рекламой сайта.
Если размещения ссылок на ресурсы, посвященные ПО Квик и расширением терминала quik в форуме компании - производителя quik запрещено, внесите этот пункт в правила и размещение ссылок прекратится.
в первый раз я об этой проблеме писал в 14 или 15 году. Был получен ответ "будет исправлено" и отправлено в помойку. Напоминал ли я об этой проблеме в промежутке между 14 годом или 15 - я не помню.
ссылка дана на сообщение 18 года, где я очередной раз озвучил проблему и получил "будет исправлено". Результат там же и что в 14 году.
в 20 году я снова вернулся к этой проблеме - ответом удостоен не был.
сейчас я опять написал о проблеме уже в этой ветке - оказывается, для вас это снова новость.
извините, но поверить в утверждение о "тщательности" в работе с пожеланиями и тем более багрепортами никак не получается, а вот улыбку они вызывают.
по остальным ошибкам, перечисленными мной выше и о тех, что я забыл написать, вы точно также можете спросить у поиска по форуму.
Egor Zaytsev написал: Он не заменяет "горизонтальный объём", который представляет собой графическое отображение фактически проторгованного объёма по ценовым уровням за указанный временной отрезок.
mihail достаточно подробно расписал и я с его интерпритацией полностью согласен: "горизонтальный объём", представляет собой графическое отображение фактически проторгованного объёма по ценовым уровням за указанный временной отрезок. Поскольку это сейчас и скорее всего Вы будете делать через поток обезличенных сделок, то там есть понятие Покупка/продажа. Ну и собственно сам рассматриваемый период тоже важен, т.к. он напрямую влияет на картину обьемов.
Я думаю, что не имею право тут делать ссылки на решения в других платформах, которые есть на рынке, но хотя бы базовая реализация обьемов.
s_mike@rambler.ru написал: Есть ошибки (не пожелания, а ошибки) , которые были изначально. не устранены до сих пор, несмотря на многократные багрепорты и "будет исправлено"
Можно список подобных проблем (с указанием их номеров)?
да вы издеваетесь!
вот навскидку ,первое пришедшее на память из того, что я сообщал в этом форуме сам.
при смене инструмента в режиме связанных окон не вызывается функция индикатора ondestroy
функция createdatasource возвращает успех в некоторых случаях даже если инструмент не существует
чтение getitem для несуществующего элемента таблицы возвращает мусор вместо ошибки. Мусор не всегда можно идентифицировать даже костылями, он похож на нормальные данные. Проблема возникает при асинхронной по отношению к скрипту очистке хранилища терминала
установка большого количества меток на диаграмме рушит терминал.
и так далее.
по всем этим историям было получено "проблема обнаружена, будет исправлено".
номера проблем, трамвайных билетиков и цифр Спортлото не спрашивайте.
Ещё раз: есть понятие приоритета. У нас нет физической возможности сделать всё и сразу -------------------------------------------------------------------------------------------------------------------------------------------
Qlua появилась в терминале 6 лет назад. Или 7? Есть ошибки (не пожелания, а ошибки) , которые были изначально. не устранены до сих пор, несмотря на многократные багрепорты и "будет исправлено"
Это не приоритеты. Это не "все и сразу". Это
-- или "мы не в состоянии это сделать" - тогда непонятны обещания исправить
-- или "и так пойдет, не облезете" - самый вероятный ответ, сходя из происходящего.
А про нехватку ресурсов нужно писать руководству, а не пользователям. Это "информация для внутреннего пользования, выкладывать её куда-то наружу...."
s_mike@rambler.ru написал: Однажды, несколько лет назад, я зарегистрировал предложение. Мне его обещали рассмотреть. На том дело кончилось, видимо рассмотрение затянулось. Через пару лет я еще раз сделал в этом форуме то же самое предложение. О чудо, оно было рассмотрено (никто ни словом не обмолвился, что такое предложение уже было раньше и именно от меня).
Добрый день.
Вы действительно считаете, что мы наизусть помним все зарегистрированные пожелания в разрезе тех никнэймов, от которых они заводились? Причём на горизонте нескольких лет? Лестно читать подобное конечно, но по факту это выглядит так: сотрудник видит что пожелание "по делу" и заводит его, если пожеланий по одной теме накапливается всё больше и больше - это может изменить приоритет по ней.
Цитата
s_mike@rambler.ru написал: А вы мне рассказываете по какое-то "большое внимание", про "фиксируются", "повышают приоритет".. Ох уж мне эти сказочки, ох уж эти мне сказочники...
И про внимание, и про фиксацию, и про возможность повышения приоритета - чистая правда. Раз Вы считаете это "сказками" - так зачем же здесь пишите? Ради флейма? У нас здесь тематический форум, настоятельно рекомендуем воздержаться от подобного.
Я понимаю, что сбор и регистрация пожеланий пользователей необходима для исполнения неких формальных протоколов и имеет отдаленное отношение к реальной работе по их реализации.
но ошибки! ошибки, иногда серьезные, иногда прямо противоречащие написанному в официальной документации. , признанные, подтвержденные, по которым многократно получен ответ "будет исправлено" вы не исправляете. Годами.
Можно рвать тельняшку и клясться про внимание, приоритеты и работу в поте лица - практика не подтверждает.
Roman Azarov написал: Как было озвучено раннее, мы постараемся рассмотреть возможность указывать вкладку при создании окна и принять решение о реализации данного функционала в будущих версиях ПО.
6 лет пытаетесь рассмотреть))) всё никак не получается.
Может, имеет смысл предложить руководству перестать играть в эти игры, чтобы и компания, и ее сотрудники техподдержки не выглядели смешно? Вам самому комфортно?
Добрый день!
Мы с большим вниманием относимся к пожеланиям пользователей, однако заметим, что у нас нет возможности сделать "все и сразу", так как помимо заметного конечным пользователям функционала работа идет и над массой других проектов.
Все пожелания пользователей, поступившие в службу технической поддержки, фиксируются, им присваивается внутренний номер. При их рассмотрении к реализации учитывается их влияние на систему "в целом", поскольку небольшое изменение в одном месте может потребовать доработки множества других модулей. Также, важно понимать, что помимо реализации пользовательских пожеланий, у нас присутствуют задачи с гораздо большим приоритетом, актуальные для всего рынка.
Увеличение количества пользователей с пожеланиями об одном и том же конкретном функционале повышает его приоритет и вероятность его реализации в ближайшем будущем (с учетом ранее озвученных моментов). Надеемся на ваше понимание и благодарим за обратную связь.
Роман,
Однажды, несколько лет назад, я зарегистрировал предложение. Мне его обещали рассмотреть. На том дело кончилось, видимо рассмотрение затянулось. Через пару лет я еще раз сделал в этом форуме то же самое предложение. О чудо, оно было рассмотрено (никто ни словом не обмолвился, что такое предложение уже было раньше и именно от меня). В результате рассмотрения оно было "признано целесообразным" и далее по тексту. Прошло два года. Вы не поверите. Я снова сделал то же предложение. И оно снова было рассмотрено! И опять оказалось, что оно очень целесообразно!
Вот до сих пор жду, когда же наконец..... Хотя мусорную корзину уборщица наверняка давно вынесла на помойку.
А вы мне рассказываете по какое-то "большое внимание", про "фиксируются", "повышают приоритет".. Ох уж мне эти сказочки, ох уж эти мне сказочники...
А еще была ошибка, которая сначала не признавалась, потом я писал тест, на котором она была видна, потом вы соглашались, потом "исправим с самом ближайшем обновлении", потом прошло года три, я снова натыкаюсь на эту же ошибку, снова пишу в форум, мне снова говорят, что это я сам дурак, я отсылаю к первому обсуждению.... Болото.
Roman Azarov написал: Как было озвучено раннее, мы постараемся рассмотреть возможность указывать вкладку при создании окна и принять решение о реализации данного функционала в будущих версиях ПО.
6 лет пытаетесь рассмотреть))) всё никак не получается.
Может, имеет смысл предложить руководству перестать играть в эти игры, чтобы и компания, и ее сотрудники техподдержки не выглядели смешно? Вам самому комфортно?
s_mike@rambler.ru написал: технических проблем вот так сходу не вижу
А я навскидку вижу следующие: 1) после dofile надо будет откатить глобальный скоуп в состояние до dofile. В принципе возможно. 2) тело скрипта и OnInit выполняются в контексте квика, пока поток main еще не создан, тут они будут в контексте проксирующего мейна выполняться. 3) квик определяет, какие колбеки будет дергать, после выполнения тела скрипта, перед вызовом OnInit и созданием мейна и потом свое мнение уже не меняет. 4) как быть с OnStop? Квик, раз уж его дернул, виснет до завершения или прибития мейна.
вызов dofile исполняется в виде корутины. Завершение отлаживаемого скрипта - обычный error.
касаемо колбеков - да, в прокси придется получать все колбеки и отдавать их в отлаживаемый скрипт. Да, задача не на 3 строчки текста, а на целых 15.
впрочем, может быть проще клацать по кнопкам в окне, я не готов настаивать.
Скользящая средняя по индикатору объёма, Добавить скользящую среднюю на объёмы с настройкой периода и параметров отображения(цвет, толщина, выше или ниже гистограмм)
Игорь написал: Добрый день. При торговле на выход из диапазона или из треугольника ожидается, что цена может пойти вверх или вниз. Но куда - не известно. И было бы чудесно иметь возможность выставить одновременно две заявки "стоп-лимит", одну на покупку, другую на продажу. Но важно - если срабатывает одна, то другая должна автоматически сниматься!!! Есть такая возможность в Квике?
Io.open создаёт в памяти объект - дескриптор. Даже после закрытия этот объект остаётся в памяти до момента прохода сборщиком мусора.
обьект маленький, поэтому при стандартных настройках сборщика (200%) нет необходимости его чистить. Когда количество таких дескрипторов станет достаточно большим, сборщик их все уберет. Либо увеличивайте агрессивность сборщика, либо вызывайте его принудительно, но лучше не делайте вообще ничего, все будет хорошо и без вашего участия.
s_mike@rambler.ru написал: Нет, не подтвердилось. Инструмент на графике один
Инструмент или источник данных? Ведь у одного инструмента могут быть графики от разных источников, таблица текущих торгов или обезличенные сделки. Если говорить про индикаторы, то они само собой рассчитываются чуть позже появления графика-источника.
А это НЕ задание SP как числа - это всё тот же грёбаный "антиллехт"! Вот если написать: float SP=0; это было бы уже задание SP как числа! Не говоря уже про int SP=0; - о таком я и мечтать не смею!
Цитата
И наша рекомендация, на оборот, везде в индексах использовать числа, а не строки.
Блин, я ПЕРЕДАВАЛ! Ещё хуже! Только на строки надежда, ибо в Lua вообще ничего нет, кроме строк! Кстати, для интерпретатора это НОРМАЛЬНО! Между прочим, я вообще отказался передавать в таблицы Lua и числа, и строки -- язык путает ключи с индексами, а потому надежнее перебить все строки таблицы заново! Маразм? Конечно! А что делать?
Просим предоставить пример такого случая, а также скрипт, на котором проявляется проблема.
Скрипт большой.
Я не прошу помощи в написании скрипта. Я спрашиваю про устройство терминала. Возможна ли такая ситуация в принципе или я неправильно диагностировал проблему.
В цикле проверяется одно и то же условие. Цена инструмента НА ГРАФИКЕ должна быть между 0 и 114800
14:03:57 > [RTS Пробой уровня вниз] CONDITION: 114370.0 < 114800 and 114370.0 > 0 14:03:57 > [RTS Пробой уровня вниз] Результат: (boolean) true
14:03:59 > [RTS Пробой уровня вниз] CONDITION: 114360.0 < 114800 and 114360.0 > 0 14:03:59 > [RTS Пробой уровня вниз] Результат: (boolean) true
14:04:01 > [RTS Пробой уровня вниз] CONDITION: 114350.0 < 114800 and 114350.0 > 0 14:04:01 > [RTS Пробой уровня вниз] Результат: (boolean) true
14:04:03 > [RTS Пробой уровня вниз] CONDITION: 114350.0 < 114800 and 114350.0 > 0 14:04:03 > [RTS Пробой уровня вниз] Результат: (boolean) true
14:04:05 > [RTS Пробой уровня вниз] CONDITION: 0.0 < 114800 and 0.0 > 0 14:04:05 > [RTS Пробой уровня вниз] Результат: (boolean) false
14:04:07 > [RTS Пробой уровня вниз] CONDITION: 114350.0 < 114800 and 114350.0 > 0 14:04:07 > [RTS Пробой уровня вниз] Результат: (boolean) true
среди нормально полученных значений в 15-04-05 (время локальных часов, наверное это начало новой свечи в торговой системе) время от времени (нерегулярно) появляется значение 0.
Roman Azarov написал: s_mike@rambler.ru, добрый день!
Просим предоставить пример такого случая, а также скрипт, на котором проявляется проблема.
Скрипт большой.
Я не прошу помощи в написании скрипта. Я спрашиваю про устройство терминала. Возможна ли такая ситуация в принципе или я неправильно диагностировал проблему.