PFelix (Все сообщения пользователя)

Сергей, ответьте, пожалуйста, Вы ведь читали тему. Вероятно я невнятно выразился: неудобство - это тормоза страшЕнные.

Здравствуйте.
Не хочется создавать отдельную тему. Поэтому пишу сюда.
Столкнулся с неудобством. Индикатор(ы) на lua (назовем их пользовательскими) использует данные других графиков - тоже написанных как индикаторы на lua (возможно некоторые часто используемые значения, рассчитываемые по данным из ТВС, назовем их техническими).
При обновлении/добавлении пользовательских индикаторов, как понял, всегда пересчитываются технические.
Есть ли возможность управлять данным процессом, Если нет, - прошу принять заявку для реализации такой возможности.
Спасибо.

Всем огромное спасибо

Здравствуйте.
При написании индикатора столкнулся с проблемой:
конструкция
cndl,_,_=getCandlesByIndex(Settings.Name_gr,0,index - 1,1)
         local PH = cndl[0].high
         local PL = cndl[0].low
иногда выдает PH = 0 и PL - тоже
Но я хочу написать универсальный индикатор, который бы использовал на входе любой график (и с нулевыми значениями тоже)
Как сделать проверку на корректность данных?
Спасибо.

Еще раз, спасибо.

Сергей, речь идет (принципиально) о двух вариантах
Если в одном пакете в quik пришла информация о 50 сделках
1. сначала пройдут все 50 калбеков, а потом разом или опосредованно будут заполнены 50 строк ТВС
2. 50 сделок будут обработаны по порядку:
- вызов калбека, далее заполнение строки ТВС;
- вызов калбека, далее заполнение строки ТВС;
и так 50 раз?
Спасибо.

Сергей, 50 калбеков разом/порцией.

Представьте, если алгоритм программы в калбеке фиксирует только факт появления новой сделки, в этот момент ее в ТВС еще нет, а предыдущаа есть/ точно есть/есть с вероятностью в зависимости от скорости следования сделок.

Я имел ввиду большую очередь "текущих" данных/калбеков, когда quik/qlua обрабатывают калбеки (тики - OnAllTrade на RI в момент стопа),
т.е. данные пришли порцией и информацией о 50-ти (например) сделках.
И в этот момент обрабатываются калбеки не последовательно в том смысле, что калбек, следом заполнение строки в ТВС, а проходит одним чохом 50 (или меньше, но несколько) калбеков, и только потом они все одним чохом оседают в ТВС?

Сергей, здравствуйте,
Скажите, пожалуйста.
Может ли сформироваться ситуация (при "подписке" на ликвидный инструмент, в момент какого-нибудь стопа), когда
основной поток не успевает складывать данные в хранилище, т.е. приходит калбек, а данные, переданные в предыдущий(ие),
в хранилище еще не поступили.
Спасибо.

А есть ли какая-либо приоритетность калбека, устанавливаемого SetUpdateCallback     (от CreateDataSource) и OnAllTrade?

Спасибо

Сергей, здравствуйте.
Не нашел в описании.
Я правильно понимаю?
В калбеке получим индекс (номер строки), с которым "идем" в таблицу обезличенных сделок?

Здравствуйте.
В версии 7 в ТВС появился OI
Как его получить в QLUA, не из таблицы истории а именно из ТВС?
Спасибо.

Перепутал ветки.
https://forum.quik.ru/messages/forum1/message10849/topic195/?result=reply#message10849

На FINAMe для учебных БИРЖА не транслирует, По видимому у Вас - также
Какой класс?,  бумага RIZ5. Не транслирует не только в ТВС, не транслирует ВООБЩЕ.

Здравствуйте,
Скажите, пожалуйста, БИРЖА для учебных серверов OI в ТВС (обезличенных), а так понял, НЕ ТРАНСЛИРУЕТ?

Спасибо. А БИРЖА для учебных серверов OI,  а так понял, НЕ ТРАНСЛИРУЕТ.

Здравствуйте! Прошу прощения указал      НЕ     UID
Предоставьте, пожалуйста доступ к таблице всех сделок (для срочного). UID:94251
Спасибо

Добрый день!
Предоставьте, пожалуйста доступ к таблице всех сделок (для срочного). UID:97590
Заранее

Спасибо, уже предоставили

Здравствуйте!
Предоставьте пожалуйста доступ к срочному рынку, UID:97590
Спасибо.

Спасибо, всем ФИНАМ работает.
Теперь другой вопрос.
В Таблице обезличенных сделок OI не транслируется, Финам говорит: это биржа поток данных для демо-серверов такой шлет.
Всё верно?

Здравствуйте, подскажите, плиз, кто из брокеров работает для версий 7,0 и выше.
Серверное 5,0 и выше, а еще на "ДЕМО"?
Спасибо.

Не странно ли. Доработка уже была реализована, но ошибочно. Т.е. проверка "на непротиворечивость общей политики компании", как понимаю, пройдена давно.
Или фарс лояльности к пользователю продолжается.

Здравствуйте Михаил,
Но теперь Вы дорабатываете доработку, которая ни к чему не привела. Вы даже не удосужились проверить, работает ли Ваш алгоритм.
Count мы получили. Но к чему он. Вы уверяете, что с его помощью можно составить таблицу изменения параметров, а в действительности - нельзя.
Если сервис QLUA не должен обеспечивать цельность данных, может, это и не ошибка. Но в доработке-то это именно так.
Ждали год - получили совершенно непотребную вещь.
В чем проблема-то? Ведь, сделать это проще простого.

Михаил, здравствуйте.
Не сочтите за ... претензии.
Однако, если перечитать историю постов и сложить в 1 копилку аргументы АРКА, логика -- "не строится".
Ваши "сложности" мы тоже готовы понять.И как потребители мы о проблеме (решения с Вашей стороны) видим со своей стороны в режиме информационного вакуума. А верить в невозможность решения, как минимум, "не хочется".
Принимая во внимание обеспечения минимума вычислений (исключения отдельного потока данных для каждого пользователя) для решения настоящей проблемы необходимо (и как понимаю, достаточно), чтобы сервер QUIK передавал в поле Count номер строки таблицы изменения параметра по инструменту (если она на сервере хранится).
Если не хранится, Михаил, то: https://forum.quik.ru/forum10/topic84/   Дмитрий пишет (23.02.2015 19:29:22):
"Вообще интересно, как именно, то есть на основе каких данных разработчики строят в терминале Таблицу изменений параметров".Если эти предложения не выход, можете изложить в каком виде эти данные на сервере хранятся? Спасибо.

PS. https://forum.quik.ru/messages/forum10/message4000/topic444/?result=reply#message4000

Никак.
Подозреваю, что таблица приходит полными строками, т.к. на завтра, добавив в таблицу изменений параметров колонку, мы получаем ее в QUIK с данными.
А басни про отсутствие "лишних" данных и настройки QUIK - это для понтов.

PS. Нужен не номер п/п изменения параметра, а номер п/п ВСЕХ изменений (т.е. в списке по изменениям всех параметров, на которые подписан клиент посредством CreateDatasource, либо всех изменений по инструменту).
"всех изменений по инструменту"  подразумевается, как таблица изменений параметров приходит в QUIK. Подозреваю, -- что полностью, т.к. на завтра, добавив в таблицу  изменений параметров колонку, мы получаем ее в QUIK с данными.
С первым изменением в новой секунде,Count можно -- снова с единицы.
Спасибо.

Всех приветствую.
Форум сменился -- проблемы остались.
Проблему подтверждаю. Тема обсуждается более года. 1,5 месяца "изучал" проблему, чтоб не создавать мусора в форуме.
11 июня 2014 на support@quik.ru было написано письмо. 1,5 месяца убеждал разработчиков в существовании проблемы, наличие которой они признавать отказывались. Номер пожелания CQ01481558, который они выполнили способом, который не привел к положительному результату.
В чем проблема? Господа разработчики? Если Вы выполняете чей-то заказ по скрытому игнорированию доработок QUIK по определенным направлениям, напишите открыто, мы поймем.
В задницу CreateDatasource, обойдемся DDE. Увеличим трафик и нагрузку на комп.
Если обидел напрасно, простите великодушно.
Если нужна помощь, поможем. Всё же уже сделано, осталось уточнить откуда брать Count.
Спасибо.