Были ли изменения в последних версиях в поле count структуры datetime?
Спасибо.
Пасхалочка для Алексея Иванникова:
QUIK clients support
Сообщений: Регистрация: 27.01.2015
24.04.2015 11:21:37
Добрый день.
Некоторые изменения с полем count были. Версии 6.15
Таблица, возвращаемая функцией T(), для объекта созданного через CreateDatasource расширилось еще одним полем – count. Поле необходимо для корректного собирания истории изменений параметра на тиковом интервале. Новый формат таблицы: {year, month, day, week_day, hour, min, sec, ms, count}
Других изменений не было.
Пользователь
Сообщений: Регистрация: 30.01.2015
24.04.2015 12:59:28
В колбеках типа onalltrade изменений не было?
Пасхалочка для Алексея Иванникова:
Пользователь
Сообщений: Регистрация: 01.02.2015
24.04.2015 14:23:06
вы неправильные (с точки зрения псевдомаретинга) вопросы задаёте. вы попробуйте задать "правильные вопросы" (список которых ещё предстоит узнать)
Пользователь
Сообщений: Регистрация: 01.02.2015
24.04.2015 14:25:06
они вам потом скажут, что: читайте форум или:.. быть может, даже и другой... (попробуйте поискать информацию на другом форуме) это п..ц в общем.
Некоторые изменения с полем count были. Версии 6.15
Таблица, возвращаемая функцией T(), для объекта созданного через CreateDatasource расширилось еще одним полем – count. Поле необходимо для корректного собирания истории изменений параметра на тиковом интервале. Новый формат таблицы: {year, month, day, week_day, hour, min, sec, ms, count}
Других изменений не было.
Кстати, была уже такая тема давно, но вот что-то не нашел (может еще на старом форуме), по проблеме: Сейчас по полю count невозможно состыковать значения отдельных параметров. Т.к. у разных параметров разное кол-во изменений count в пределах секунды. Если на тиковый график бросить пару параметров, напр, кол-во сделок и цену последней, то графики окажутся не корректно синхронизированными. Можете проверить сами. Вроде даже регистрировали пожелание на доработку.
Но ведь это тянет на ошибку, особенно в случае с рассинхронизацией графиков. Можете переквалифицировать доработку в ошибки и побыстрее поправить? (ну и чтобы через API появилась возможность корректно синхронизировать параметры по тикам)
Michael Bulychev
Гость
24.04.2015 14:30:53
Цитата
s_mike@rambler.ru пишет: В колбеках типа onalltrade изменений не было?
s_mike@rambler.ru пишет: В колбеках типа onalltrade изменений не было?
Добрый день, Михаил. А что там не так?
Михаил, Здравствуйте.
Возможно, я чего-то не понимаю, но мне кажется странной такая ситуация.
Получая таймсерию инструмента по подписке, я вижу в результатах поле count, что позволяет корректно работать со сделками, имеющими одиаковое время. Тут все хорошо.
Теперь я подписываюсь на onalltrade и смотрю, что мне дают. Поля count в таймштампе здесь нет. Синхронизации результатов подписки и колбека невозможна, хотя напрашивается.
Насколько я ничего не понимаю, если копнуть поглубже, исходные данные для обоих источников информации изначально одни и те же. Если это так - поле count хотелось бы увидеть и в соответствующих on-колбеках.
Еще странность. Если мне не изменяет память, то в данных, которые мы получаем по подписке, отсутствует поле микросекунд, а в результатах колбека это поле есть.
Пользуясь случаем. В вашем даташтампе фигурирует поле week_day, в стандарном datetime формате lua 5.1 - wday
Пасхалочка для Алексея Иванникова:
Пользователь
Сообщений: Регистрация: 14.02.2015
24.04.2015 15:55:54
Цитата
Теперь я подписываюсь на onalltrade и смотрю, что мне дают. Поля count в таймштампе здесь нет. Синхронизации результатов подписки и колбека невозможна, хотя напрашивается.
Если не секрет, и простите если за возможную глупость, но зачем синхронизировать OnAllTrade и колбэк DataSource для сделок?
Пользователь
Сообщений: Регистрация: 31.01.2015
24.04.2015 16:06:16
Цитата
latrop1 пишет: Кстати, была уже такая тема давно, но вот что-то не нашел (может еще на старом форуме), по проблеме: Сейчас по полю count невозможно состыковать значения отдельных параметров. Т.к. у разных параметров разное кол-во изменений count в пределах секунды. Если на тиковый график бросить пару параметров, напр, кол-во сделок и цену последней, то графики окажутся не корректно синхронизированными. Можете проверить сами.
Вот эти темы, созданные как до появления поля count, так и после его появления (которое фактически ничего не дало):
Цитата
latrop1 пишет: Вроде даже регистрировали пожелание на доработку.
Но ведь это тянет на ошибку, особенно в случае с рассинхронизацией графиков. Можете переквалифицировать доработку в ошибки и побыстрее поправить?
Присоединяюсь к пожеланию переквалифицировать доработку на исправление ошибок и побыстрее поправить.
Между тем прошло уже больше месяца с момента регистрации пожелания, а мы до сих пор даже не узнали о результатах его анализа:
Цитата
Sergey Gorokhov пишет: 20.03.2015 09:56:35
Здравствуйте!
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Теперь я подписываюсь на onalltrade и смотрю, что мне дают. Поля count в таймштампе здесь нет. Синхронизации результатов подписки и колбека невозможна, хотя напрашивается.
Если не секрет, и простите если за возможную глупость, но зачем синхронизировать OnAllTrade и колбэк DataSource для сделок?
Например, арбитражная синтетика, где важны не только цены, но и порядок следования сделок. alltrade даёт последовательность, а datasource - готовые таймсерии по ногам.
Пасхалочка для Алексея Иванникова:
Пользователь
Сообщений: Регистрация: 31.01.2015
27.04.2015 17:44:34
Цитата
Дмитрий пишет: Вот эти темы, созданные как до появления поля count, так и после его появления (которое фактически ничего не дало):
Я немного ошибся при указании ссылки на старый форум (первой из двух) с предыдущим обсуждением проблемы. По приведенной мною ссылке ( , в третьем снизу сообщении), а также и по этой ссылке: пользователь PFelix жаловался на то, что добавление поля Count не решило ту проблему, которую он описал вот здесь (почти год назад):
Пользователь
Сообщений: Регистрация: 30.04.2015
30.04.2015 06:11:38
Всех приветствую. Форум сменился -- проблемы остались. Проблему подтверждаю. Тема обсуждается более года. 1,5 месяца "изучал" проблему, чтоб не создавать мусора в форуме. 11 июня 2014 на support@quik.ru было написано письмо. 1,5 месяца убеждал разработчиков в существовании проблемы, наличие которой они признавать отказывались. Номер пожелания CQ01481558, который они выполнили способом, который не привел к положительному результату. В чем проблема? Господа разработчики? Если Вы выполняете чей-то заказ по скрытому игнорированию доработок QUIK по определенным направлениям, напишите открыто, мы поймем. В задницу CreateDatasource, обойдемся DDE. Увеличим трафик и нагрузку на комп. Если обидел напрасно, простите великодушно. Если нужна помощь, поможем. Всё же уже сделано, осталось уточнить откуда брать Count. Спасибо.
Пользователь
Сообщений: Регистрация: 01.02.2015
30.04.2015 06:32:53
Цитата
PFelix Paulossky пишет: Если Вы выполняете чей-то заказ по скрытому игнорированию доработок QUIK по определенным направлениям, напишите открыто, мы поймем.
)))об этом, вам никто и никогда не признается))) однако... структура акционеров "арки", утёкшая в интернет - многое объясняет...)))
Пользователь
Сообщений: Регистрация: 30.04.2015
30.04.2015 06:47:42
PS. Нужен не номер п/п изменения параметра, а номер п/п ВСЕХ изменений (т.е. в списке по изменениям всех параметров, на которые подписан клиент посредством CreateDatasource, либо всех изменений по инструменту). "всех изменений по инструменту" подразумевается, как таблица изменений параметров приходит в QUIK. Подозреваю, -- что полностью, т.к. на завтра, добавив в таблицу изменений параметров колонку, мы получаем ее в QUIK с данными. С первым изменением в новой секунде,Count можно -- снова с единицы. Спасибо.
Michael Bulychev
Гость
30.04.2015 08:21:39
Цитата
PFelix Paulossky пишет: PS. Нужен не номер п/п изменения параметра, а номер п/п ВСЕХ изменений (т.е. в списке по изменениям всех параметров, на которые подписан клиент посредством CreateDatasource, либо всех изменений по инструменту). "всех изменений по инструменту" подразумевается, как таблица изменений параметров приходит в QUIK. Подозреваю, -- что полностью, т.к. на завтра, добавив в таблицу изменений параметров колонку, мы получаем ее в QUIK с данными. С первым изменением в новой секунде,Count можно -- снова с единицы. Спасибо.
Добрый день. нет нужды упражняться в конспирологии. На данный момент в Lua мы отдали все что смогли. Проблема не забыта и мы постараемся дать доступ из lua к таблице истории изменений параметров.
Пользователь
Сообщений: Регистрация: 01.02.2015
30.04.2015 08:51:29
Цитата
Michael Bulychev пишет: На данный момент в Lua мы отдали все что смогли.
а дать пользователям нормально работать с qchart.dll из qlua надо понимать, не смогли?
Michael Bulychev пишет: На данный момент в Lua мы отдали все что смогли.
а дать пользователям нормально работать с qchart.dll из qlua надо понимать, не смогли?
Повторю еще раз - qchart не предназначен для пользования сторонними средствами, это не "плагин"
Пользователь
Сообщений: Регистрация: 30.04.2015
30.04.2015 09:29:08
Михаил, здравствуйте. Не сочтите за ... претензии. Однако, если перечитать историю постов и сложить в 1 копилку аргументы АРКА, логика -- "не строится". Ваши "сложности" мы тоже готовы понять.И как потребители мы о проблеме (решения с Вашей стороны) видим со своей стороны в режиме информационного вакуума. А верить в невозможность решения, как минимум, "не хочется". Принимая во внимание обеспечения минимума вычислений (исключения отдельного потока данных для каждого пользователя) для решения настоящей проблемы необходимо (и как понимаю, достаточно), чтобы сервер QUIK передавал в поле Count номер строки таблицы изменения параметра по инструменту (если она на сервере хранится). Если не хранится, Михаил, то: Дмитрий пишет (23.02.2015 19:29:22): "Вообще интересно, как именно, то есть на основе каких данных разработчики строят в терминале Таблицу изменений параметров".Если эти предложения не выход, можете изложить в каком виде эти данные на сервере хранятся? Спасибо.
Пользователь
Сообщений: Регистрация: 23.01.2015
30.04.2015 09:46:18
Цитата
PFelix пишет: чтобы сервер QUIK передавал в поле Count номер строки таблицы изменения параметра по инструменту (если она на сервере хранится).
Не хранится
Цитата
PFelix пишет: Если эти предложения не выход, можете изложить в каком виде эти данные на сервере хранятся? Спасибо.
Они хранятся в том виде как приехали. И на рабочее место они приезжают в том же виде. Проблема возникает при попытке воспроизвести ту хронологию в которой эти данные приехали. И как сказал Михаил, сейчас мы УЖЕ работаем над тем чтобы эту проблему преодолеть. В виду сказанного не считаю разумным вести диалог дальше.
Michael Bulychev пишет: На данный момент в Lua мы отдали все что смогли.
а дать пользователям нормально работать с qchart.dll из qlua надо понимать, не смогли?
Повторю еще раз - qchart не предназначен для пользования сторонними средствами, это не "плагин"
конкретно в этой ветке, я и не говорил, что это плагин. А спросил лишь о том, почему его возможности не в полной мере реализованы в qlua, хотя, возможность сделать эту dll более user-friendly у вас определённо имеется. И, кстати, Михаил, вы мне так и не ответили: ---------------- получается, для вас - доступен весь функционал и спектр возможностей, а нам вы оставляете только тривиальные функции использования.
Пользователь
Сообщений: Регистрация: 01.02.2015
30.04.2015 10:35:20
и ещё: с радостью от вас выслушаю Вашу версию того, что вы считаете плагином... :)))
Пользователь
Сообщений: Регистрация: 23.01.2015
30.04.2015 10:43:26
Цитата
sam063rus пишет: и ещё: с радостью от вас выслушаю Вашу версию того, что вы считаете плагином... ))
Все просто, то что в меню Справка - Версии компонентов, имеет возможность установить галку - то плагин, все остальное служебные составляющие
У нас есть тестовые сервера и на них информация не обязана совпадать с боевой.
Пользователь
Сообщений: Регистрация: 01.02.2015
30.04.2015 11:02:06
честно говоря, ответ на троечку бо как тестируя обращения и пожелания, т.е. выявленные баги от пользователей на, как вы говорите, тестовых серверах, которые не ведут себя, как боевые - вы тем самым потом нам же и пишете, что мол де данная проблема, у вас не воспроизводится... :))) --- полагаю, тут не о чем больше тогда говорить.
Пользователь
Сообщений: Регистрация: 23.01.2015
30.04.2015 11:07:30
Цитата
sam063rus пишет: честно говоря, ответ на троечку бо как тестируя обращения и пожелания, т.е. выявленные баги от пользователей на, как вы говорите, тестовых серверах, которые не ведут себя, как боевые - вы тем самым потом нам же и пишете, что мол де данная проблема, у вас не воспроизводится.
Расскажите, как по Вашему, что изменило бы в диагностике, если бы проблему воспроизводили на боевом потоке?
Пользователь
Сообщений: Регистрация: 01.02.2015
30.04.2015 11:13:11
я думаю, для вас далеко не секрет, что помимо самих данных огромное значение имеет последовательность их поступления, а также ряд других параметров потока данных, которые вам доступны и нет смысла их тут озвучивать. (говорим сейчас, я так понимаю уже обобщённо)
sam063rus пишет: и ещё: с радостью от вас выслушаю Вашу версию того, что вы считаете плагином... ))
Все просто, то что в меню Справка - Версии компонентов, имеет возможность установить галку - то плагин, все остальное служебные составляющие
)))) ок. не буду настаивать и спорить )))
to Михаил: мой вопрос #21 всё ещё в силе.
Там два вопроса, на какой именно нужен ответ?
Пользователь
Сообщений: Регистрация: 01.02.2015
30.04.2015 11:19:30
Михаил - уже ни на какой - будем считать, что Сергей Вас спас. А то топик рискует превратиться в роман в четырёх томах (война и мир). самое главное, что те кто должен был понят - уже давно всё понял...
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
30.04.2015 17:23:46
Цитата
Sergey Gorokhov пишет: Расскажите, как по Вашему, что изменило бы в диагностике, если бы проблему воспроизводили на боевом потоке?
Если бы воспроизводили проблемы на боевом Квике, то вопрос уже решили бы.
Надо делать так, как надо. А как не надо - делать не надо.
Sergey Gorokhov пишет: Расскажите, как по Вашему, что изменило бы в диагностике, если бы проблему воспроизводили на боевом потоке?
Если бы воспроизводили проблемы на боевом Квике, то вопрос уже решили бы.
А теперь расскажите как проблема с индикатором связанна с проблемой описанной на этой ветке форума
Пользователь
Сообщений: Регистрация: 23.01.2015
30.04.2015 17:49:41
Данный топик постепенно превращается в какой-то суд. история по ссылке от sam063rus разобрана, баг найден но пока еще не починен. история по ссылке от Серж разобрана, баг найден уже починен. И при этом утверждается что мы не так диагностируем. В чем вопрос вообще не понятно. с праздниками Вас
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
30.04.2015 18:13:02
Цитата
Sergey Gorokhov пишет: история по ссылке от Серж разобрана, баг найден уже починен
В какой версии? В v.6.17.1.17 окно ввода стоп-заявки по опционам открывается более 8 сек. Почему в списках исправлений версий нет информации об этом баге?
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 23.01.2015
30.04.2015 18:17:06
Цитата
Серж пишет: В какой версии? В v.6.17.1.17 окно ввода стоп-заявки по опционам открывается более 8 сек. Почему в списках исправлений версий нет информации об этом баге?
В версии 6.16.1 Если у Вас проблема повторяется, то это уже новая тема для разбора.
Серж пишет: В какой версии? В v.6.17.1.17 окно ввода стоп-заявки по опционам открывается более 8 сек. Почему в списках исправлений версий нет информации об этом баге?
В версии 6.16.1 Если у Вас проблема повторяется, то это уже новая тема для разбора.
Нет, в той теме вам ясно написали, что проблема наблюдается в т.ч. и на v.6.16.1.15. После чего вам предложено было воспроизвести проблему при подключении к боевому серверу. Как я понял, этого сделано не было...
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 31.01.2015
30.04.2015 22:48:58
Цитата
Michael Bulychev пишет: На данный момент в Lua мы отдали все что смогли. Проблема не забыта и мы постараемся дать доступ из lua к таблице истории изменений параметров.
Если для вас вместо доработки QLua будет проще реализовать возможность ручного сохранения в файл содержимого Таблицы изменений параметров точно в том виде, в каком она отображается на экране, то сделайте, пожалуйста, хотя бы это для начала. Соответствующее пожелание у вас уже вроде как зарегистрировано под номером CQ01579578. Существующие на данный момент средства сохранения этой таблицы через буфер обмена или DDE не работают при большом количестве столбцов или строк из-за нехватки памяти (). Как сообщила мне ваша служба техподдержки, эту проблему невозможно решить без перехода на 64-разрядную версию терминала. Поэтому желание построить такую таблицу с помощью средств QLua лично у меня появилось, как говорится, не от хорошей жизни.
Пользователь
Сообщений: Регистрация: 30.01.2015
30.04.2015 23:00:45
Цитата
Дмитрий пишет: реализовать возможность ручного сохранения в файл содержимого Таблицы изменений параметров
Ну будет вам... Берите готовое и экспортируйте историю параметров
Пасхалочка для Алексея Иванникова:
Пользователь
Сообщений: Регистрация: 31.01.2015
30.04.2015 23:32:02
Цитата
s_mike@rambler.ru пишет: Ну будет вам... Берите готовое и экспортируйте историю параметров
Спасибо, но из сохраненных Вашим скриптом данных об изменениях отдельных параметров (когда таких изменений несколько в пределах одной секунды) точно так же невозможно собрать достоверную таблицу истории изменений параметров, по причинам, описанным выше в этой ветке, а также по этой ссылке: