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

Наличие флага "ответ от сервера получен" не лишает вас возможности использовать колбек.

Nikolay, не могу похвастаться уровнем работы с высокими материями, новичёк ещё. Поэтому, если позволите, взгляд со стороны, неопытного программиста.

Не хватает признака отсутствия данных, мы об этом.
Хотите туда количество? Да, пожалуйста, просите разработчиков. Как будете использовать - ваше дело.

Конечно, информация есть, как минимум список классов, но не обязательно график.
Чтоб вы понимали, как это работает (на примере графика цены и объёма):
Когда вы вызываете CreateDataSource, она проверяет валидность класса, и, в случае успеха, тут же выплёвывает вам data_source. Причём, возможны несколько вариантов:
1) Если график уже открыт, то CreateDataSource сразу выдаст вам заполненный data_source.
Если график не открыт, то:
2) Если клиент оффлайн и находит в кеше нужный бинарник, то в data_source будут свечи из этого бинарника.
3) Если клиент оффлайн и графика в кеше нет, то data_source будет пустой (Size = 0).
4) Если клиент онлайн, то data_source будет пустой (Size = 0) до тех пор, пока не получит хоть одну свечу.

Может, не было, а может, было, не узнаешь, пока не пройдёт хоть одна сделка. См. выше, четвёртый пункт.

Здравая мысль, просите разработчиков. Но, насколько мне известно, до недавнего времени у сервера отсутствовала функция мониторинга "почему сломался график." Не знаю, может, появилось что-то.

А кто с этим спорит? Мы пока не знаем, что "там" есть.

Вам сюда.

И второй вариант:

И вдогонку (учитывая опыт), а то опять не поймёте: то что написано в OnParam, заполнение нашего поля, делает естественно сам терминал по приходу ответа от сервера на запрос CreateDataSource, мы ведь об нём тему мусолим.

Nikolay, вы меня троллите что ли?
Зачем вам эта информация?

Псевдокод, OnParam взят только в качестве иллюстрации:
Так понятнее?

Не правильно. Ответ тот же, что и для Sergey Gorokhov, читайте выше:
https://forum.quik.ru/messages/forum10/message46438/topic5543/#message46438

DS:Чё_Есть_На_Сервере_Брокера() обращается к объекту DS (data_source), только возвращает нам не какую-то лабуду, а честный ответ: если сервер ещё ничё не прислал, то и ответ будет буквально "ничё", nil. Ежели с сервера уже получили ответ, то там будет признак наличия/отсутствия свечей на сервере.

Anton, я вот тут подумал, это тогда, когда клиент хранил историю в 3000+ свечей количество свечей на сервере могло пригодиться. Сейчас, когда сервер хранит 3000+, а клиент 65 тыс. количество свечей на сервере не особо то поможет, скорее навредит. Важен только сам факт есть там свечи или нет.

Так, писать вы научились. Теперь учитесь читать:

Или количество свечей на сервере (вместо флага) в предыдущей редакции. (Ну запамятовал я, что такое пожелание уже было.)

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


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

К сожалению, у вас так и останутся вопросы пока, наконец, вы не поймёте, что ds:Size() не обращается напрямую к серверу, а возвращает количество свечей на рабочем месте.

Признаться, я уже и запамятовал, что там регистрировалось 3 года назад. Случайно вчера наткнулся на старую тему.

Я давно заприметил функцию UpdateRow в QLua. Что это за функция такая, что она делает?

Да, Highlight, конечно жёстко тормозит вывод. Но у меня получается наоборот, чем меньше timeout в Highlight, тем плавнее обновляется вторая строка.

Согласен, пример неудачный, дисконект. Потом - новая сессия, пакеты прошлой сессии не в счёт.

Кажется, я понял. Sergey Gorokhov, похоже, вы думаете, что ds:Size() напрямую обращается к серверу. Поверьте, это не так. Size() возвращает то количество свечей, которое получил и для него посчитал клиент на месте и участливо положил в датасорс. Можете спросить у старших.

Не вижу логики. Сервер отправляет ответ по транзакции автору этой транзакции, а не другому клиенту. Если сервер не повторил отправку неподтверждённого пакета, то вопрос к серверу, почему? Если же это клиент получил, но не вызвал колбек, - то к клиенту.
У меня больше вопрос, почему, если поставить sleep побольше и транзакция не успевает отправиться до дисконекта, то нет сообщения об ошибке. Скорее всего, sendTransaction только проверяет валидность параметров и доступность указанной транзакции и сразу возвращает результат этой проверки, а саму транзакцию ставит в очередь на отправку. А когда доходит до отправки, то уже дисконект. Но в этом случае клиент должен уведомить, хотя бы вызовом того же OnTransReply с соответсвующим сообщением.

На рабочее место загружено такое-то количество свечей. По другому - никак.
Я и не настаиваю на интерпретации "окончания загрузки". Об "окончании загрузки" можно с уверенностью говорить только по завершении торгов, когда известно, что свечей не прибавится.
Дадут ds:ServerSize() будем с ним работать )) Вариант
тоже вполне рабочий для определённых целей.

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

Скрытый текст

Цитата Anton написал: Дык он не теряется, насколько мне известно, в потоке ответ есть, колбек не дергается почему-то. Можете проверить, если будет желание. Имитация разрыва соединения с сервером: Код w32 = require('w32') run = true trans_id = 123 function OnStop()   run = nil end function main()   -- Разорвать соединение с сервером   w32.PostMessage(w32.FindWindow('InfoClass', ''), 0x0111, 101, 0)   sleep(100) -- Тут надо отрегулировать задержку, чтобы транзакция гарантированно была отправлена серверу   -- При большой задержке sendTransaction отрабатывает без ошибки, хотя по факту транзакция не отправлена (?)   if not isConnected() == 1 then     message('Not connected', 3)     return   end   local transaction = {     TRANS_ID = ""..trans_id,     ACTION = "NEW_ORDER",     ACCOUNT = account,     CLIENT_CODE = client,     CLASSCODE = class_code,     SECCODE = sec_code,     OPERATION = "B",     TYPE = "L",     PRICE = price,     QUANTITY = "1"   }   local err = sendTransaction(transaction)   if err == "" then message('sendTransaction: OK', 2)   else message(err, 3) end   while run do sleep(1000) end end function OnDisconnected()   message('OnDisconnected', 2) end function OnTransReply(trans_reply)   message('OnTransReply:\n' .. trans_reply.result_msg, 2) end function OnOrder(order)   if order.trans_id == trans_id then     message('OnOrder: OK', 2)   end end После восстановления соединения получаем OnOrder. OnTransReply не вызывается. Повторяет ли сервер отправку неподтвержденного OnTransReply не знаю.

Скрытый текст
Anton, вот здесь конкретная формулировка, аналогичная вашему предложению. Следующий комментарий от Sergey Gorokhov показывает отсутствие понимания, что данные не могут мгновенно появиться, для него сервер - что-то локальное.

А что с тиками не так?

Anton,
https://forum.quik.ru/messages/forum10/message22935/topic2397/#message22935

Проблема в том, что Sergey Gorokhov, не понимает, что данные по сетям передаются не мгновенно, требуется какое-то время, пока клиент их получит. Конечно, откуда ему знать, он же в одной сети со своим игровым сервером QUIK Junior сидит. У него всё приходит, как с локального сервера, быстрее, чем он может подумать. Да и нет там такого объёма трафика, чтобы были задержки какие-то.
Вот и говорит Sergey Gorokhov, вот вам ds:Size(). Если там ноль, значит свечей нет. И невдомёк ему, что в реальном мире всё не так. А пока Sergey Gorokhov, предложение не одобрит, оно не будет принято. Модератор, однако.

Три года назад я это предлагал.
Вообще моё предложение, вроде, как не противоречит механизму клиент-серверного общения по протоколу TCP "Запрос-Ответ":
Клиент посылает запрос серверу, тот в ответ либо сразу пушит данные, если они есть, либо отвечает, что данных нет. Пока нет. Они, может быть, и появятся когда-нибудь, но мы этого не знаем.
А что делать с этой информацией вы уже решаете сами.

Скрытый текст
И если немного отвлечься от темы, то механизм TCP гарантирует уведомление отправителя о результатах передачи. И почему ответ OnTransReply на транзакцию может потеряться - сие остаётся загадка.

Меня тоже печалят такие предложения. Но ваш комментарий к этой теме никаким боком не относится.

Anton, задачи, ведь, могут быть разные, как считаете?
Есть, скажем, задача обработать стотыщ графов: отрыть каждый, посчитать чё-то там, закрыть, чтоб память не жрал, выдать результат. Может быть такая задача? Почему нет?
Можно, конечно, работать и в колбеках, наплодить стотыщ data_source и ждать когда Квик рухнет с нехваткой памяти.
Ну это как спорить: как правильно, делать всю работу в main или в колбеках. Нет однозначного ответа. Для каждой задачи нужен свой подход.

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

2) Если data_source создан, то клиент чё-то там отправляет серверу, в ответ последний отправляет клиенту запрашиваемые свечи или флаг, что свечей сервер не имеет.

3) После получения данных с сервера клиент заполняет у себя data_source (если свечи имеются) и флаги true/false.

Ежели мы запросим DS:Чё_Есть_На_Сервере_Брокера() между 2 и 3, то получим nil, потому что флаги ещё не пришли с сервера, про биты помните?

Тут же, вроде, и объект не должен создаваться и CreateDataSource вернёт ошибку, не?

Anton, написал выше. Я не говорю про "все данные загружены".

nil - это, когда вы запрашиваете DS:Чё_Есть_На_Сервере_Брокера() до того, как клиент получил информацию с сервера. Биты, они, ведь, не мгновенно передаются, понимаете?

Из понимания, как оно должно работать. Сервер обязан уведомить клиента как о наличии свечей (тогда он сразу передаёт сами свечи), так и об отсутствии свечей (флаг false).
Вы же сами пишите:
А вот мы не знаем, возвращает ли сервер что-то, если графика нет. Клиент сразу создаёт пустой объект. Как понять, что сервер уже чё-то вернул?
В вашем случае ожиданиеможет привести к бесконечному циклу.

Сравните:


Про false

Sergey Gorokhov,
Рассмотрите на примере http-сервера.
Когда запрашиваемой страницы нет, но есть заглушка, вы видите страницу 404.
Если заглушки нет, то вы будете целый день сидеть перед пустым монитором или пока не надоест. Придумали в прошлом веке, а вы говорите "десятки лет"...

Вы сейчас о какой именно ошибке?
Последние два поста я вам пишу о ситуации, когда задан валидный инструмент, но графика нет по нему.

А как понять, что сервер уже вернул эти пустые значения? Они ведь у вас по дефолту и так возвращаются. Пусть, скажет, что у него нет свечей, чтоб не ждать понапрасну.

Типа такой функции что ли:

DS:Чё_Есть_На_Сервере_Брокера()
true - свечи есть
false - нет свечей
nil - информации о наличии свечей пока нет, но она обязательно будет, приходите позже

Машину времени изобретаете? Об этом никто и не спрашивал.
Пусть сервер скажет: у меня свечей нет сейчас, узбагойся чувак. Но он же ж молчит, аки партизан. А ты крутись, программер, как хошь.

session_status обновляется независимо от ТТТ?

Это не "странно", это баг. Что за data_source возвращается в таком случае, вообще не понятно:

Если залогиниться в QUIK под другим пользователем (не закрывая программу), то на открытых графиках остаются треугольники от сделок и линии заявок от предыдущего пользователя.

Предлагаю вместо неинформативного false в OnConnected передавать имя нового класса.

Я так понимаю, вопрос возник, когда в os.time() был передан какой-нибудь квиковский datetime = {year=1601, month=1, day=1, hour=0}
Если в 5.1 тут возвращался nil, и с ним можно было работать, то теперь перед вызовом os.time надо проверить, как минимум год, чтобы не получить исключение

Имелось ввиду результат в 5.1 и 5.3 одинаковый, на зависимо от таймзоны, за исключением случаев с отрицательным временем.

Часовой пояс, как бы, ни при чём.
В 5.1 если дата была меньше 0, os.time возвращал nil, с которым в общем-то можно было работать.
В 5.3 в этом случае вы увидите "time result cannot be represented in this installation".

Тов. из QUIK software testing обещал разобраться с этим. И пропал. Видимо, разбирается.
Но, если есть обращения к таблице в main внутри цикла while isRun do, тут уже сложнее.
Чтобы QUIK не подвисал при остановке, и скрипт корректно завершался, первым делом в OnStop удаляю идентификатор таблицы.

"Отступ от мин" есть в заявке на покупку. Это то, что вам нужно.

Тогда вот:

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

От двух пользователей, на одном компе, одновременно. Интересно, зачем это может понадобиться?
Да пожалуйста, ставьте квик в Users\%USERNAME%
Ответ тот же.

Скрытый текст
Ещё не хватало, чтобы Арка заморачивалась с профилями, групповыми политиками и прочая

Сделать другие значки для скриптов:
1) остановившихся в результате ошибки;
2) в которых возникла ошибка, но скрипт продолжил работу (ошибка в колбеке)

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

Egor Zaytsev, я знаю, как работало и как стало работать в 8.5. А вы, похоже, не знаете.

Egor Zaytsev, создайте две таблицы с разными инструментами. После чего откройте и покажите фильтры каждой из них.

Было бы неплохо, если бы наконец устранили древнюю проблему, когда цвета таблицы, установленные из скрипта в SetColor, сбрасываются при применении фильтра.

Как в 8.5.2 увидеть фильтр для открытой таблицы обезличенных сделок (не общий фильтр, а именно для конкретной ТОС)?

Сделать функцию для изменения названий колонок в QLua-таблицах.

Не правда, не было.

Ответ в категориях "наверное", "по идее" и т.п. не устраивает. Мы с вами не баллистические ракеты проектируем  
Можете пригласить тов. Nikolay Pavlov, надеюсь он сможет что-то конкретное сказать.

getTradeDate() в OnCleanUp всегда даёт актуальную дату торговой сессии или это у меня так совпало?

Скрытый текст
Чтобы не вставать два раза, поясню: В данной теме обсуждается проблема получения в OnCleanUp параметра "Дата торгов" через запрос getInfoParam("TRADEDATE"). И действительно данный запрос в OnCleanUp возвращает дату предыдущей торговой сессии. Как обстоит дело с getTradeDate()?

getTradeDate() в OnCleanUp всегда даёт актуальную дату торгов или это у меня так совпало?

Зачем?

Пример без InsertRow:

Результат:


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