function main()
if sendTransaction{
TRANS_ID = tostring(trans_id),
ACTION = "NEW_ORDER",
ACCOUNT = account,
CLIENT_CODE = client,
CLASSCODE = class_code,
SECCODE = sec_code,
OPERATION = "B",
TYPE = "L",
PRICE = price,
QUANTITY = "1"
} == "" then run = true end
while run do sleep(1) end
end
function OnTransReply(trans_reply)
if trans_reply.trans_id ~= trans_id then return end
run = nil
sendTransaction{
TRANS_ID = tostring(trans_id + 1),
ACTION = "KILL_ORDER",
CLASSCODE = class_code,
ORDER_KEY = tostring(trans_reply.order_num)
}
end
function OnStop()
run = nil
end
Надо делать так, как надо. А как не надо - делать не надо.
С учетом sleep(1) есть неиллюзорные шансы, что мейн завершается раньше sendTransaction из колбека. Что будет, если в OnTransReply строку run = nil перенести после sendTransaction?
Дополнительно просим направить следующую информацию, необходимую для анализа проблемы, на почту нашей поддержки (quiksupport@arqatech.com): - наименование Вашего брокера - адрес сервера, при подключении к которому была замечена данная проблема - Ваш UID - номера заявок, у которых было замечено данное поведение (не приходит значение поля "UID снявшего заявку")
Также, в письме просим указать ссылку на данную тему форума. Заранее благодарим.
Старатель написал: Я не понял: наблюдаете или нет? Запустите предложенный скрипт на своём демо.
Согласитесь, то, что речь про демо-сервер - вообще не очевидно было по вопросу. А проблема скорее всего именно в сервере, который не заполняет, потому и важно уточнить какой он.
Roman Azarov, В заявках, снятых транзакцией "KILL_ORDER", не заполняется UID снявшего, если транзакция снята вскоре после выставления. В 8.11 наблюдается в junior. В заявках, снятых в результате транзакций "MOVE_ORDERS" на FORTS и "Изменение заявки" на ФР, UID снявшего не заполняется в любом случае. Наблюдается как на демо, так и на боевом.
Будете ли вы это исправлять в своём ПО - это ваше решение.
Надо делать так, как надо. А как не надо - делать не надо.
swerg написал: Согласитесь, то, что речь про демо-сервер
Да, как оказалось, отсутствие canceled_uid в заявках для "KILL_ORDER" относится к только демо-серверу. В боевом квике все заявки без canceled_uid были сняты "MOVE_ORDERS".
Надо делать так, как надо. А как не надо - делать не надо.
По вашему обращению мы диагностируем проявление ошибки в серверном ПО QUIK, в результате которой при быстром снятии заявки по классу QJSIM на демо-сервере, не прописывается canceled_uid на снятой заявке. Мы постараемся исправить эту ошибку в одной из ближайших версий серверного ПО QUIK.
Приносим вам свои извинения за доставленные неудобства.
Данная проблема нами не разбиралась. Вынуждены повториться (в третий раз в данной теме), для ее анализа необходимо:
Цитата
Roman Azarov написал: Дополнительно просим направить следующую информацию, необходимую для анализа проблемы, на почту нашей поддержки ( quiksupport@arqatech.com ): - наименование Вашего брокера - адрес сервера, при подключении к которому была замечена данная проблема - Ваш UID - номера заявок, у которых было замечено данное поведение (не приходит значение поля "UID снявшего заявку") - дата наблюдения проблемы Также, в письме просим указать ссылку на данную тему форума.
Если Вы наблюдаете у себя описанное ранее в ветке, просьба предоставить запрошенную информацию.
Прошу прощения, действительно, упустили из виду тот момент, что проблема с MOVE_ORDERS на срочном рынке воспроизводится также и на нашем учебном сервере. Проблема изучается, постараемся в ближайшее время дать ответ.
По вашему обращению мы диагностируем проявление ошибки в серверном ПО QUIK, в результате которой при перестановке заявки на срочном рынке не прописывается canceled_uid на снятой заявке. Мы постараемся исправить ошибку в одной из ближайших версий ПО.
Приносим вам свои извинения за доставленные неудобства.
Старатель написал: В заявках, снятых в результате транзакций "MOVE_ORDERS" на FORTS и "Изменение заявки" на ФР, UID снявшего не заполняется в любом случае. Наблюдается как на демо, так и на боевом.
Ошибку в серверном ПО QUIK сами найдёте?
Надо делать так, как надо. А как не надо - делать не надо.
Старатель написал: Не совсем понятно, для чего привлекать брокера
Важно понимать, что ошибка, проявляющаяся на сервере брокера (не эта в частности), далеко не всегда будет каким-либо образом воспроизводиться у нас (как минимум, без повторения условий воспроизведения со стороны серверного ПО). Разные версии сервера, разные конфигурации и еще много других нюансов. Точно также, устранение проблемы на демо, вовсе не обязательно приведет к скорейшему устранению проблемы на боевом сервере брокера (как минимум потому, что конкретно Ваш брокер не узнает о проблеме и не поторопится ее исправить (иными словами, обновить ПО)).
Цитата
Старатель написал: Это уже без меня. Я не могу быть заинтересован в исправлении ошибок вашего ПО больше, чем вы сами.
Повторимся, у себя данной проблемы не обнаружили. Речь не о заинтересованности, а о том, что без Вашей помощи (так как обратились именно Вы), проанализировать и устранить ненаблюдаемую проблему не представляется возможным. Если для Вас данная проблема более не актуальна, то обращение будем вынуждены закрыть.
Roman Azarov, о вашей заинтересованности говорит реакция на обращения (не только в этой теме): спустя три недели после сообщения о MOVE_ORDERS:
Цитата
Roman Azarov написал: Данная проблема нами не разбиралась.
Так ка на самом деле
Цитата
Незнайка написал: заполняется ли вообще поле сервером при перестановке заявок
или нет? О каких разных конфигурациях вы пишите, когда эта проблема общего характера. И рассматривать её надо не в частном порядке.
Цитата
Roman Azarov написал: устранение проблемы на демо, вовсе не обязательно приведет к скорейшему устранению проблемы на боевом сервере брокера
MOVE_ORDERS - это ведь проблема не демо, не так ли? Как только (и если) ошибка будет исправлена, и брокер накатит обновление, canceled_uid будет заполняться и на серверах брокера. Некоторые брокеры устанавливают обновления сразу после их выпуска, другие - прежде тестируют на своём тестовом контуре. Это решение брокера, что и когда обновлять.
Цитата
Roman Azarov написал: обращение будем вынуждены закрыть
Моё дело малое: сообщить об обнаруженной проблеме разработчику ПО. Если это никому не надо, так мне тем более.
Надо делать так, как надо. А как не надо - делать не надо.
Старатель написал: или нет? О каких разных конфигурациях вы пишите, когда эта проблема общего характера. И рассматривать её надо не в частном порядке.
Часто пользователю мерещится, что возникшая у него ошибка - ошибка самого общего характера. проявляющаяся у всех, ведь он жмет на единственную красную кнопку на пульте. Казалось бы, все жму на эту кнопку, а значит проблема имеет общий характер, кнопка не работает, очевидно же! Однако в таких ситуациях не редко оказывается так, что ошибка эта вовсе не носит общего характера, даже при наличии единственной кнопки на пульте, а проявляется лишь в редких экзотических условиях.
Это я вам как коллега коллеге подсказываю.
Я к тому, что, как это модно говорить, "просьба отнестись с пониманием" к запросам о помощи Миру мир и всё такое.