Некоторые изменения с полем count были. Версии 6.15
Таблица, возвращаемая функцией T(), для объекта созданного через CreateDatasource расширилось еще одним полем – count. Поле необходимо для корректного собирания истории изменений параметра на тиковом интервале. Новый формат таблицы: {year, month, day, week_day, hour, min, sec, ms, count}
Некоторые изменения с полем count были. Версии 6.15
Таблица, возвращаемая функцией T(), для объекта созданного через CreateDatasource расширилось еще одним полем – count. Поле необходимо для корректного собирания истории изменений параметра на тиковом интервале. Новый формат таблицы: {year, month, day, week_day, hour, min, sec, ms, count}
Других изменений не было.
Кстати, была уже такая тема давно, но вот что-то не нашел (может еще на старом форуме), по проблеме: Сейчас по полю count невозможно состыковать значения отдельных параметров. Т.к. у разных параметров разное кол-во изменений count в пределах секунды. Если на тиковый график бросить пару параметров, напр, кол-во сделок и цену последней, то графики окажутся не корректно синхронизированными. Можете проверить сами. Вроде даже регистрировали пожелание на доработку.
Но ведь это тянет на ошибку, особенно в случае с рассинхронизацией графиков. Можете переквалифицировать доработку в ошибки и побыстрее поправить? (ну и чтобы через API появилась возможность корректно синхронизировать параметры по тикам)
s_mike@rambler.ru пишет: В колбеках типа onalltrade изменений не было?
Добрый день, Михаил. А что там не так?
Михаил, Здравствуйте.
Возможно, я чего-то не понимаю, но мне кажется странной такая ситуация.
Получая таймсерию инструмента по подписке, я вижу в результатах поле count, что позволяет корректно работать со сделками, имеющими одиаковое время. Тут все хорошо.
Теперь я подписываюсь на onalltrade и смотрю, что мне дают. Поля count в таймштампе здесь нет. Синхронизации результатов подписки и колбека невозможна, хотя напрашивается.
Насколько я ничего не понимаю, если копнуть поглубже, исходные данные для обоих источников информации изначально одни и те же. Если это так - поле count хотелось бы увидеть и в соответствующих on-колбеках.
Еще странность. Если мне не изменяет память, то в данных, которые мы получаем по подписке, отсутствует поле микросекунд, а в результатах колбека это поле есть.
Пользуясь случаем. В вашем даташтампе фигурирует поле week_day, в стандарном datetime формате lua 5.1 - wday
Теперь я подписываюсь на onalltrade и смотрю, что мне дают. Поля count в таймштампе здесь нет. Синхронизации результатов подписки и колбека невозможна, хотя напрашивается.
Если не секрет, и простите если за возможную глупость, но зачем синхронизировать OnAllTrade и колбэк DataSource для сделок?
latrop1 пишет: Кстати, была уже такая тема давно, но вот что-то не нашел (может еще на старом форуме), по проблеме: Сейчас по полю count невозможно состыковать значения отдельных параметров. Т.к. у разных параметров разное кол-во изменений count в пределах секунды. Если на тиковый график бросить пару параметров, напр, кол-во сделок и цену последней, то графики окажутся не корректно синхронизированными. Можете проверить сами.
latrop1 пишет: Вроде даже регистрировали пожелание на доработку.
Но ведь это тянет на ошибку, особенно в случае с рассинхронизацией графиков. Можете переквалифицировать доработку в ошибки и побыстрее поправить?
Присоединяюсь к пожеланию переквалифицировать доработку на исправление ошибок и побыстрее поправить.
Между тем прошло уже больше месяца с момента регистрации пожелания, а мы до сих пор даже не узнали о результатах его анализа:
Цитата
Sergey Gorokhov пишет: 20.03.2015 09:56:35
Здравствуйте!
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Теперь я подписываюсь на onalltrade и смотрю, что мне дают. Поля count в таймштампе здесь нет. Синхронизации результатов подписки и колбека невозможна, хотя напрашивается.
Если не секрет, и простите если за возможную глупость, но зачем синхронизировать OnAllTrade и колбэк DataSource для сделок?
Например, арбитражная синтетика, где важны не только цены, но и порядок следования сделок. alltrade даёт последовательность, а datasource - готовые таймсерии по ногам.
Всех приветствую. Форум сменился -- проблемы остались. Проблему подтверждаю. Тема обсуждается более года. 1,5 месяца "изучал" проблему, чтоб не создавать мусора в форуме. 11 июня 2014 на support@quik.ru было написано письмо. 1,5 месяца убеждал разработчиков в существовании проблемы, наличие которой они признавать отказывались. Номер пожелания CQ01481558, который они выполнили способом, который не привел к положительному результату. В чем проблема? Господа разработчики? Если Вы выполняете чей-то заказ по скрытому игнорированию доработок QUIK по определенным направлениям, напишите открыто, мы поймем. В задницу CreateDatasource, обойдемся DDE. Увеличим трафик и нагрузку на комп. Если обидел напрасно, простите великодушно. Если нужна помощь, поможем. Всё же уже сделано, осталось уточнить откуда брать Count. Спасибо.
PFelix Paulossky пишет: Если Вы выполняете чей-то заказ по скрытому игнорированию доработок QUIK по определенным направлениям, напишите открыто, мы поймем.
)))об этом, вам никто и никогда не признается))) однако... структура акционеров "арки", утёкшая в интернет - многое объясняет...)))
PS. Нужен не номер п/п изменения параметра, а номер п/п ВСЕХ изменений (т.е. в списке по изменениям всех параметров, на которые подписан клиент посредством CreateDatasource, либо всех изменений по инструменту). "всех изменений по инструменту" подразумевается, как таблица изменений параметров приходит в QUIK. Подозреваю, -- что полностью, т.к. на завтра, добавив в таблицу изменений параметров колонку, мы получаем ее в QUIK с данными. С первым изменением в новой секунде,Count можно -- снова с единицы. Спасибо.
PFelix Paulossky пишет: PS. Нужен не номер п/п изменения параметра, а номер п/п ВСЕХ изменений (т.е. в списке по изменениям всех параметров, на которые подписан клиент посредством CreateDatasource, либо всех изменений по инструменту). "всех изменений по инструменту" подразумевается, как таблица изменений параметров приходит в QUIK. Подозреваю, -- что полностью, т.к. на завтра, добавив в таблицу изменений параметров колонку, мы получаем ее в QUIK с данными. С первым изменением в новой секунде,Count можно -- снова с единицы. Спасибо.
Добрый день. нет нужды упражняться в конспирологии. На данный момент в Lua мы отдали все что смогли. Проблема не забыта и мы постараемся дать доступ из lua к таблице истории изменений параметров.
Михаил, здравствуйте. Не сочтите за ... претензии. Однако, если перечитать историю постов и сложить в 1 копилку аргументы АРКА, логика -- "не строится". Ваши "сложности" мы тоже готовы понять.И как потребители мы о проблеме (решения с Вашей стороны) видим со своей стороны в режиме информационного вакуума. А верить в невозможность решения, как минимум, "не хочется". Принимая во внимание обеспечения минимума вычислений (исключения отдельного потока данных для каждого пользователя) для решения настоящей проблемы необходимо (и как понимаю, достаточно), чтобы сервер QUIK передавал в поле Count номер строки таблицы изменения параметра по инструменту (если она на сервере хранится). Если не хранится, Михаил, то: https://forum.quik.ru/forum10/topic84/ Дмитрий пишет (23.02.2015 19:29:22): "Вообще интересно, как именно, то есть на основе каких данных разработчики строят в терминале Таблицу изменений параметров".Если эти предложения не выход, можете изложить в каком виде эти данные на сервере хранятся? Спасибо.
PFelix пишет: чтобы сервер QUIK передавал в поле Count номер строки таблицы изменения параметра по инструменту (если она на сервере хранится).
Не хранится
Цитата
PFelix пишет: Если эти предложения не выход, можете изложить в каком виде эти данные на сервере хранятся? Спасибо.
Они хранятся в том виде как приехали. И на рабочее место они приезжают в том же виде. Проблема возникает при попытке воспроизвести ту хронологию в которой эти данные приехали. И как сказал Михаил, сейчас мы УЖЕ работаем над тем чтобы эту проблему преодолеть. В виду сказанного не считаю разумным вести диалог дальше.
Michael Bulychev пишет: На данный момент в Lua мы отдали все что смогли.
а дать пользователям нормально работать с qchart.dll из qlua надо понимать, не смогли?
Повторю еще раз - qchart не предназначен для пользования сторонними средствами, это не "плагин"
конкретно в этой ветке, я и не говорил, что это плагин. А спросил лишь о том, почему его возможности не в полной мере реализованы в qlua, хотя, возможность сделать эту dll более user-friendly у вас определённо имеется. И, кстати, Михаил, вы мне так и не ответили: https://forum.quik.ru/messages/forum8/message2549/topic124/#message2549 ---------------- получается, для вас - доступен весь функционал и спектр возможностей, а нам вы оставляете только тривиальные функции использования.
честно говоря, ответ на троечку бо как тестируя обращения и пожелания, т.е. выявленные баги от пользователей на, как вы говорите, тестовых серверах, которые не ведут себя, как боевые - вы тем самым потом нам же и пишете, что мол де данная проблема, у вас не воспроизводится... :))) --- полагаю, тут не о чем больше тогда говорить.
sam063rus пишет: честно говоря, ответ на троечку бо как тестируя обращения и пожелания, т.е. выявленные баги от пользователей на, как вы говорите, тестовых серверах, которые не ведут себя, как боевые - вы тем самым потом нам же и пишете, что мол де данная проблема, у вас не воспроизводится.
Расскажите, как по Вашему, что изменило бы в диагностике, если бы проблему воспроизводили на боевом потоке?
я думаю, для вас далеко не секрет, что помимо самих данных огромное значение имеет последовательность их поступления, а также ряд других параметров потока данных, которые вам доступны и нет смысла их тут озвучивать. (говорим сейчас, я так понимаю уже обобщённо)
Михаил - уже ни на какой - будем считать, что Сергей Вас спас. А то топик рискует превратиться в роман в четырёх томах (война и мир). самое главное, что те кто должен был понят - уже давно всё понял...
Данный топик постепенно превращается в какой-то суд. история по ссылке от sam063rus разобрана, баг найден но пока еще не починен. история по ссылке от Серж разобрана, баг найден уже починен. И при этом утверждается что мы не так диагностируем. В чем вопрос вообще не понятно. с праздниками Вас
Sergey Gorokhov пишет: история по ссылке от Серж разобрана, баг найден уже починен
В какой версии? В v.6.17.1.17 окно ввода стоп-заявки по опционам открывается более 8 сек. Почему в списках исправлений версий нет информации об этом баге?
Надо делать так, как надо. А как не надо - делать не надо.
Серж пишет: В какой версии? В v.6.17.1.17 окно ввода стоп-заявки по опционам открывается более 8 сек. Почему в списках исправлений версий нет информации об этом баге?
В версии 6.16.1 Если у Вас проблема повторяется, то это уже новая тема для разбора.
Серж пишет: В какой версии? В v.6.17.1.17 окно ввода стоп-заявки по опционам открывается более 8 сек. Почему в списках исправлений версий нет информации об этом баге?
В версии 6.16.1 Если у Вас проблема повторяется, то это уже новая тема для разбора.
Нет, в той теме вам ясно написали, что проблема наблюдается в т.ч. и на v.6.16.1.15. После чего вам предложено было воспроизвести проблему при подключении к боевому серверу. Как я понял, этого сделано не было...
Надо делать так, как надо. А как не надо - делать не надо.
Michael Bulychev пишет: На данный момент в Lua мы отдали все что смогли. Проблема не забыта и мы постараемся дать доступ из lua к таблице истории изменений параметров.
Если для вас вместо доработки QLua будет проще реализовать возможность ручного сохранения в файл содержимого Таблицы изменений параметров точно в том виде, в каком она отображается на экране, то сделайте, пожалуйста, хотя бы это для начала. Соответствующее пожелание у вас уже вроде как зарегистрировано под номером CQ01579578. Существующие на данный момент средства сохранения этой таблицы через буфер обмена или DDE не работают при большом количестве столбцов или строк из-за нехватки памяти (https://forum.quik.ru/forum1/topic58/). Как сообщила мне ваша служба техподдержки, эту проблему невозможно решить без перехода на 64-разрядную версию терминала. Поэтому желание построить такую таблицу с помощью средств QLua лично у меня появилось, как говорится, не от хорошей жизни.
s_mike@rambler.ru пишет: Ну будет вам... Берите готовое и экспортируйте историю параметров
Спасибо, но из сохраненных Вашим скриптом данных об изменениях отдельных параметров (когда таких изменений несколько в пределах одной секунды) точно так же невозможно собрать достоверную таблицу истории изменений параметров, по причинам, описанным выше в этой ветке, а также по этой ссылке: https://forum.quik.ru/forum10/topic110/