Дмитрий (Все сообщения пользователя)

Я немного ошибся при указании ссылки на старый форум (первой из двух) с предыдущим обсуждением проблемы. По приведенной мною ссылке (http://forum-archive.quik.ru/forum/iwr/111108/?pagelength=100 , в третьем снизу сообщении), а также и по этой ссылке: http://forum-archive.quik.ru/forum/lua/121572/  пользователь PFelix жаловался на то, что добавление поля Count не решило ту проблему, которую он описал вот здесь (почти год назад):
http://forum-archive.quik.ru/forum/lua/113078/

Здравствуйте!
А до того как будет изменена документация, вы можете описать правила определения типа клиента, чтобы было понятно, какое все-таки значение должен содержать client_type для типа клиента МД?
То есть, хотелось бы понять - так и должно быть или это ошибка?

Я немного ошибся при указании ссылки на предыдущее описание проблемы. По приведенной мною ссылке (http://forum-archive.quik.ru/forum/iwr/111108/?pagelength=100 , в третьем снизу сообщении), а также и по этой ссылке: http://forum-archive.quik.ru/forum/lua/121572/
пользователь PFelix лишь жаловался на то, что добавление поля Count не решило ту проблему, которую он описал вот здесь:
http://forum-archive.quik.ru/forum/lua/113078/
Ближе к концу обсуждения там есть сообщение Михаила Булычева с таким содержанием:
Там же чуть ниже есть Ваше, Сергей Горохов, сообщение:
Все это было заявлено вами как планируемая доработка вашего софта для решения проблемы невозможности построения таблицы истории значений двух и более параметров средствами QLua.
Заявленная доработка в итоге была реализована и было добавлено поле Count. Однако значения, которые в нем возвращаются, не позволяют решить описанную выше проблему.
Поэтому PFelix, я и latrop1 считаем, что данный факт является следствием ошибки в реализации заявленного вами функционала, приводящей к его фактической неработоспособности.

Добрый день!
Неужели вы хотите поставить под сомнение факт существования данной проблемы?
Как видно из всего написанного выше в данной ветке, проблему легко обнаружить даже без использования какого-либо кода.
Причем описывалась подобная проблема еще раньше и другими пользователями (на старом форуме):
http://forum-archive.quik.ru/forum/iwr/111108/?pagelength=100
Выше (уже в этой ветке нового форума) ваш коллега подтвердил, что попытка решить проблему невозможности точного воссоздания истории изменений двух и более различных параметров путем введения дополнительного поля count оказалась неудачной:

А как можно получить отчет по транзакциям?

А почему вы думаете, что биржа сочтет возможным в данном случае предоставить такую информацию?

Вот эти темы, созданные как до появления поля count, так и после его появления (которое фактически ничего не дало):
http://forum-archive.quik.ru/forum/iwr/111108/?pagelength=100
https://forum.quik.ru/forum10/topic110/

Присоединяюсь к пожеланию переквалифицировать доработку на исправление ошибок и побыстрее поправить.

Между тем прошло уже больше месяца с момента регистрации пожелания, а мы до сих пор даже не узнали о результатах его анализа:

Меню "настройки / основные / сообщения", выбираете "сохранять за последние N дней".
После этого при необходимости сообщения за прошлые дни можно будет просмотреть в таблице через меню "сообщения / системные сообщения / таблица сообщений..."

А как же понимать ответ по поводу проблемы, описанной по этой ссылке: https://forum.quik.ru/forum1/topic58/
который был получен мною два месяца назад от вашей службы поддержки (от Егора Зайцева):

Она бесконечная - не имеет начала и конца. Автору темы наверное нужна линия в виде отрезка.

Однако это не мешает крупному брокеру раскачать на бирже цену на тонком рынке.

Хотите сказать, что сама биржа стопы сбивает чтобы подзаработать?

Если так, то берете каждый из двух концов линии и выставляете визуально на один уровень цены, пока при самом большом увеличении не выровняете ее

Наверное имелось в виду выровнять вручную линию горизонтально, а потом делать с нее копии по мере надобности и размещать их там где нужно

Это невозможно

А если сделки по этому инструменту происходят не каждую минуту, а раз в несколько минут, а то и реже?
В таком случае можно очень долго ждать...

А вы знаете способ как определить с помощью колбэка не только полное отсутствие данных, но и момент окончания их загрузки, то есть когда с сервера получена последняя свеча?

А может мой способ и является правильным? Если мне нужны только данные, накопленные до момента вызова CreateDataSource, без последующих обновлений.
А использование коллбэков сильно тормозит работу, если речь идет о получении данных по большому числу инструментов.
В Вашем же случае проблема была в том, что вы пытались обращаться к данным еще до того, как терминал успел загрузить их с сервера, а использование коллбэков отнюдь не ускорит этот процесс.

Нет, с самого утра не открывал и исторические данные за прошлые дни (файлы *.dat из подкаталога archive) при этом тоже тоже все удалены.

А я успешно получаю данные с использованием только CreateDataSource, без вызова SetEmptyCallback или SetUpdateCallback.
Причем без них работает все гораздо быстрей.
И при этом графики в терминале не открыты.
Это "ошибка" в реализации QLua? Или все же так и должно быть?

Правда я проверяю эти данные только 1 раз. Вполне возможно, что после загрузки в терминал текущего состояния графика со всей историей, дальше без использования одной из последних двух функций новые свечки уже не будут поступать.

Открывайте второй стакан по тому же инструменту нажатием F4 и выбором инструмента из списка

Добрый день! Пока что не нашел.
Возможно, потому что еще не уделял этим поискам много времени.
Думаю, начать стоит с сайта Московской биржи - moex.com

String.format вам в этом не поможет.
Используйте что-то из этого:
string.sub (возможно, вместе с string.find)
или
string.match

А скажите, если не секрет - такой выбор ОС обусловлен тем, что QUIK лучше всего работает именно под Windows XP, а не под Windows 7 или более новой?

Над этим размышлял не я один. И почему-то нам кажется, что возможно.
Чего в принципе невозможного в том, чтобы зафиксировать количество записей в наиболее важных для пользователей таблицах сервера на момент установления соединения с терминалом и затем передать сведения о количестве этих записей на терминал пользователя?

Это все понятно. Никто не просит сообщать о помидорах, не доехавших до В.
Люди хотят знать, сколько помидоров было на складе В (т.е. сколько записей в таблице на сервере брокера) только на момент подключения к нему терминала С.
И нужно это потому, что процесс передачи данных от сервера (В) до терминала (С) сразу после подключения занимает некоторое время, причем неопределенное. В это время на терминал передаются в основном данные, накопленные сервером раньше, а не только что приехавшие с биржи. И люди хотят иметь механизм точного определения того, что данные, находившиеся на сервере брокера (В) на момент установления связи с терминалом (С), наконец-то загрузились с сервера на терминал.

Видимо, число минут в часе и торговых часов в сутках (если бы торги шли круглосуточно).

Николай Бехтерев, советую вам оформлять свой код с отступами внутри циклов, а чтобы эти отступы не пропадали при размещении сообщения на форуме - пользоваться кнопочкой "оформление текста в виде кода".
Иначе бывает трудно сходу вникнуть в логику работы вашего алгоритма.

А в чем разница работы SetUpdateCallback при выборе тикового интервала и при выборе любого другого?

Это верно

А разве одного file:close() не достаточно?

А это нормально - использовать в пути слэш вместо бэкслэша ("\")?

Господа, вам не жалко времени на эти бесполезные дискуссии с троллем?
По-другому я не могу назвать человека, который "подозревает" всех пишущих тут в том, что они работают в ARQA, даже не потрудившись посмотреть их сообщения в других ветках форума (а может все-таки потрудившись...?), из которых видно, что многие из отписавшихся здесь заняты на этом форуме отнюдь не прославлением QUIK'а.
Если бы на форуме был модератор, то уже давно бы выставил здесь некоторым предупреждения за оффтоп и переход на личности. И мне, возможно тоже, за это сообщение  :)
Предлагаю больше не отвечать здесь на послания rozmin

Поскольку нас интересует только изменение текущих значений параметров, то можно наверное вместо тикового задать часовой интервал. Тогда память действительно почти не будет расходоваться.

Тут правда надо отметить, что я использовал тиковый интервал при вызове функции CreateDataSource.

Только что проверил - расходуется.
Как минимум порядка 50 байт на одно изменение параметра.
Иногда это может быть незаметно, но если отслеживать много параметров по нескольким фьючерсам, причем таких параметров, значения которых меняются очень часто (до 10 раз в секунду) - то расход памяти может достигать порядка 10 мегабайт на каждый параметр, и эту величину надо будет еще умножить на количество анализируемых фьючерсов.

Сдается мне, что такой метод работы будет отжирать оперативную память на хранение отдельной истории за текущий день по каждому отслеживаемому параметру.

Из всего вышесказанного я понял, что от биржи приходят только значения параметров, по которым были зафиксированы изменения в промежутке между двумя интервалами времени (срезами).
Можно ли в таком случае добавить в функцию OnParam(STRING class_code, STRING sec_code) еще один параметр, сообщающий, изменение значений каких именно параметров ТТП привело к вызову этой функции?
Ведь в противном случае нам приходится лишний раз вызывать функцию getParamEx для получения значений каждого интересующего нас параметра и последующего анализа их значений. В итоге может оказаться, что интересующие нас параметры не изменились, но мы проделали в скрипте кучу ненужной работы и тем самым создали лишнюю нагрузку на систему.

Или все же биржа отправляет в этом случае только текущие (последние) значения параметров?

Значит, в этой кучке содержатся не только текущие значения параметров, но и все их изменения, произошедшие за время с момента прихода предыдущей кучки?

Это понятно. Непонятно, как программа узнает об этих изменениях, если она получает данные только срезами, а эти изменения произошли в промежутке между срезами и в конечном счете на момент получения второго среза ничего не изменилось.

Это надо понимать так, что когда речь идет о получении значений ТТП срезами, то это касается лишь передачи данных от сервера QUIK в терминал, в то время как сам сервер QUIK получает с биржи и отслеживает абсолютно все изменения этих параметров непрерывно, а не срезами?

Просто непонятно в таком случае, как система вообще узнает об изменении параметра, если она отслеживает значения параметров лишь срезами через определенные промежутки времени.

То есть получается, что, с одной стороны, в терминале нет данных о том, что параметр изменился.
А с другой стороны они вроде бы в терминале есть, раз такая строка попадает в Таблицу истории значений параметров.

Но это произошло в промежутке между получением двух срезов ТТП, поэтому в итоге изменение значения этого параметры мы в терминале не увидим.

Это я видел. Отсюда лишь следует, что не все изменения значений параметров будут заметны пользователю.
Опять же из этого никак не очевидно, что эти оставшиеся незамеченными изменения повлияют на появление новых (одинаковых) строк в Таблице истории значений параметров или Таблице изменений параметров.

1) Это про Текущую таблицу параметров
2) Из этого никак явно не следует, что в Таблице истории значений параметров могут идти друг за другом полностью идентичные строки.

В документации об этом ничего не сказано, поэтому я и был озадачен...

Если после сделки изменялись другие параметры, а новых сделок не было, то появление нескольких строк с одинаковой информацией о сделке - это нормально. Вы ведь отслеживаете не только параметры сделок, но еще и другие.

Ну, если речь идет не о числовых значениях, а, например, о строковых, то да.
Но речь ведь шла о полностью совпадающих значениях всех параметров.
В таком случае мне непонятен принцип формирования этих таблиц...