Если нужна скорость поиска, нужно строить в памяти скрипта по колбеку onalltrade копии таблицы обезличенных сделок отдельно по каждому инструменту, правильно назначать ключ таблицы и мгновенно искать необходимую сделку уже в этой луа таблице. Переход на x64 позволяет это легко.
Максим написал: Здравствуйте, подскажите на языке Lua возможно написать скрипт, который автоматически бы двигал стоп-приказ за индикатором Parapolic SAR. То есть мне нужно понять можно ли с помощью языка Lua определить: 1. Открыта ли позиция по определенному активу 2. Получить текущую цену актива 3. Получить цену текущего стоп-приказа 4. Получить текущее значение индикатора Paraboic SAR 5. Изменить параметры стоп-приказа
Проверяет, является ли obj валидным хендлером файла. Возвращает строку "file" если obj – открытый хендлер файла, "closed file" если obj закрытый хендлер файла, или nil если obj не является хендлером файла.
s_mike@rambler.ru написал: сейчас, когда терминал не может внятно сказать, удачно ли он подписался на котировку,
Да и это ошибка, которую мы уже изучили и уже признали.
Цитата
s_mike@rambler.ru написал: нет возможности отследить, почему нет котировок. Или нет свечей в принципе,
да такой возможности нет, и сам сервер этого не знает. От куда серверу знать будут ли торги по инструменту или трейдеры вообще ничего сегодня не купят? никто этого знать не может и сервер тоже не может.
Цитата
s_mike@rambler.ru написал: или они ещё не получены, или подписка не прошла.
Это та же тема что и первый пункт про неправильный статус createdatasource? Если так то ответ уже был.
ответ к делу не пришьешь.
я вам писал о неправильном ответе createdatasource уже лет 5 назад и вы регистрировали, рассматривали, обсуждали, митинговали, постановили и дали торжественные обещания. Результат известен.
Sergey Gorokhov написал: s_mike@rambler.ru, Не понятно причем тут это, речь же была про подписку а не про свечи. Свечи да могут быть обрезаны с лева, нумерация при этом сдвинется.
работа с котировками инструментов у меня - единый объект, который и подписки делает и с историей работает. В том числе занимается кэшированием. Поэтому при переподключении необходимо пересоздать весь объект, который при создании переподпишется и дальше снова начнет создавать кеши котировок.
сейчас, когда терминал не может внятно сказать, удачно ли он подписался на котировку, нет возможности отследить, почему нет котировок. Или нет свечей в принципе, или они ещё не получены, или подписка не прошла.
Сергей написал: По размышлению возник вопрос, а зачем вообще при дисконнекте закрывать потоки, созданные createdatasource()? Они автоматом разве не закроются? Что вообще произойдет с открытым потоком, если соединение разорвется, а затем восстановится?
Терминал QUIK автоматом закроет поток если он не используется. При реконнекте подписка не теряется.
а разве нумерация свечей останется неизменной? Старые свечи разве не могут обрезаться?
Привяжите к окну событиe на закрытие окна, в нем устанавливаете флаг, что нужно завершить скрипт. В главном потоке время от времени этот файл просматривайте и завершайте свой скрипт.
Сам код привести довольно трудно. он весьма объёмный
при старте скрипта и всех организационных действий вызывается subscribe(), в котором в числе прочего происходит подписка на инструменты. Подписка проходит нормально при запуске скрипта, никаких проблем нет ни с имеющимся соединением с брокером, ни с отсутствующим.
Подписка на событие oncleanup выглядит элементарно:
Насколько мы правильно понимаем, демонстрируемый Вами индикатор не является стандартным графиком QUIK. Наиболее вероятно, это - индикатор, созданный сторонним разработчиком на LUA-скрипте. Поэтому для уточнения информации рекомендуем обратиться непосредственно к разработчику скрипта.
о. Арка наняла новеньких, они ещё въезжают.. ))
Евгений. Смысл поста вы том, что путем изменения настроек индикатора можно нарушать вид шкал и легенду диаграмм. Что является наглядным примером качества продукта. Да ещё как выясняется и сотрудникинсотрудники в состоянии осознать написанное.
После получения сигнала смены сессии я отписываюсь от всех инструментов и подписываюсь заново. Как понимаю, это необходимо при возможном изменении истории инструмента при смене сессии.
Подписка на инструмент сразу после смены сессии ошибок не возвращает, но и "мёд не носит" - свечи не приходят, колбек не дергается.
os_time берет секунды и первым делом отсчитывает от них часовой пояс. Если взять 0, то при часовом поясе европа получается 1969 год и луа огорчается.
касаемо 5.1. Не замечалось. Быстрее всего там была возможность работать с отрицательным юникстиме без преобразования os.date. в 5.3 решили навести порядок и при пересборке своих скриптов в режиме ВУИГП (проверках всего и вся) я и увидел эту шляпу.
Кто может написать простой скрипт на Lua для индивидуального графика-индикатора?, написать простой скрипт на Lua для индивидуального графика-индикатора
Кто может написать простой скрипт на Lua для индивидуального графика-индикатора?, написать простой скрипт на Lua для индивидуального графика-индикатора
И правда, чё там. Надо автомобиль сбацать- базару нет! Берем четыре колеса, четыре стула, эта, таво.... а! две калитки, одну мою, вторую соседскую - и пару бутылок беленькой. И забацаем до вечера. Чё мы, хуже мерина с поршом? И стоить будет 1000 рублей, из них половина - бухло.
Поддержать на словах труда никакого. Вы поддержите фининсово, оплатите необходимую вам работу - и разработчики с удовольствием все сделают. У вас есть лишние деньги , изменяющиеся сотнями тысяч рублей или все проще поставить версию 8?
Действительно, есть ошибка записи действительных значений в целочисленные колонки. Ошибка будет исправлена в будущих обновлениях ПО. Приносим извинения за причиненные неудобства.
Тогда заодно исправьте и индикаторы.Если задать в тексте на луа
Settings = { ['PARAM'] = 5, line = чегототам }
то при старте индикатора setting.Param содержит (int) 5, а после изменения его пользователем уже (float) 5.0
Sergey Gorokhov написал: s_mike@rambler.ru, по идее должно быть целое число 123 Однако как оказалось возвращается не то. Проблема изучается. Постараемся в ближайшее время дать ответ.
при записи в столбец qtable_int64_type переданное значение 123.45 всегда будет преобразовано в int64 (123) и именно в таком виде запомнено где-то в кишках терминала?
По getcell я получу уже именно как lua integer (123) ? Или я получу его как float (lua number) с обрезанной дробной частью (123.0)? или все же я получу исходный lua number 123.45?
есть тип колонки qtable-string-type. В него можно записать значение типа string
есть qtable_double_type для плавающих чисел
есть qtable_int_type. Логично предположить, что в эта колонку можно записать только integer
по факту оказывается, что в в колонки int и int64 можно писать и int и int64. Значения показываются, никаких округлений не происходит.
какая в таком случае разница между qtable_int qtable_int64 и wtable_double? Никакой.
отсутствие разницы было как то объяснимо на луа 5.1. сейчас же на луа 5.3 после введения integer типа ожидаешь соответствия, но по прежнему все валится в одну кучу
более подробно не могу. Если опять непонятно - надо уже просить помощь зала.
s_mike@rambler.ru написал: Я правильно понимаю, что колонки пользовательских таблиц этих типов по прежнему уверенным домкратом выводят float циферки? )
Приведите пример для понимания вопроса
Дорогая редакция!
Создайте пользовательскую таблицу на языке qlua, одну колонку сделайте типом QTABLE_INT64_TYPE и выведите в нее число 1.2345
Я слышал, что 1.2345 никак не есть int64. Возможно меня обманули....