Если кто делал такое штатными средствами QLua - через CTRL-S, отпишите. Ну и какой смысл вообще от виртуальной клавиши? Если она генерила бы специфический код на комбинации клавиш, тогда ещё ладно. А так, какой с неё прок?
Kalmar написал: А когда поймали - проверять, нажат ли контрол/альт/шифт
Так, погоди... Смотри... Если я как обычно жму CTRL-S, ну т.е. сначала зажимаю CTRL и при нажатом CTRL нажимаю "S", то QTABLE_CHAR не приходит вообще! Приходит только QTABLE_VKEY у кторого msg == 17. И всё! Как мне средствами Lua словить CTRL-S?
Поправлю, приходит только QTABLE_VKEY у кторого par2 == 17
Kalmar написал: А когда поймали - проверять, нажат ли контрол/альт/шифт
Так, погоди... Смотри... Если я как обычно жму CTRL-S, ну т.е. сначала зажимаю CTRL и при нажатом CTRL нажимаю "S", то QTABLE_CHAR не приходит вообще! Приходит только QTABLE_VKEY у кторого msg == 17. И всё! Как мне средствами Lua словить CTRL-S?
Мне вот приспичило CTRL-S ловить в таблице. Оказывается никак! CTRL генерит код VKEY 17 и всё. Нажатие "S" или "s" при нажатом CTRL ничего не генерит. А если CTRL нажать и не отпускать, то будет несколько сгенерённых VKEY равных 17. А так хотелось именно на CTRL-S отклик.
nikolz написал: Вы плохо изучали теорию.Повторю еще раз. Синхронизируют не код, а общие данные. Функция принт - это код.---------------------------Зачем Вы выводите в консоль? Выводивыводите в лог файл и будет вам счастье. Лог файл позволяет анализировать ошибки и логику выполнения программы при длительном тестировании софта.Например , тестировал скрипт на QUIK 6 часов. При интенсивном потоке данных или длительном тестировании от консоли мало толку. -------------------------Чтобы при выводе на консоль ничего не съедалось надо ставить задержку после оператора вывода. Обычно sleep(10) достаточно.
1) Вот только не надо мне про плохо теорию. Синхронизируется никакой не код, а общий ресурс - в данном случае это консоль. Не надо рассматривать данные только чисто как некие переменные, массивы и т.п. В моём конкретном случае делается то что нужно именно мне. Без синхронизации такой эффект я не получу. Если иными словами, могу и по другому объяснить - консоль это по сути буфер, буфер это данные, что там винда делает с этим буфером - не важно. Но суть такая же. Вам интересно услышать, что нужно синхронизировать данные общие, пожалуйста - данные это буфер консоли. Какие ещё тут могут быть вопросы? 2) Лог файлы ведутся на каждый счёт помимо консоли, а как же без них то??? При желании ведение их легко включается и отключается, но консоль нужна чисто для текущей визуализации происходящего всего, что крутится внутри одного экземпляра квика. 3) Вот только задержки со слипом после вывода это маразм какой-то. Всё работать должно без всяких слипов. 4) И да, функция принт это код, никто не спорит, но только синхронизируется не функция принт, а доступ её или их к общему ресурсы - буферу консоли.
Да с этого начинал. Так делал. У меня есть DDL-ли и они все тоже печатают в консоль. Консоль одна на весь процесс квика. Печатают в консоль все - и основной поток с его функциями, и колбэки и функции, которые лезут в DLL из нутри самой DLL и сама DLL. Как там винда это регулирует хрен её знает. У неё там видимо есть общая очередь для всех тех кто в эту консоль пишет и вот как то нихрена не синхронно в эту очередь всё попадпет. Тоесть ждёшь той последовательности вывода принтов от всех, к какой они делаются шаг за шагом и с учётом ныряния в DLL, а получается не так - идёт перемешка. То что перемешка с колбэком то это понятно может, но и просто выводы из скрипта с выводами функций, что заходят в DLL перемешка получается не в той последовательности как вызывается почему-то.Например в скрипте вывел в консоль, потом только идёт вызов функции из DLL, которя тоже выводит в консоль и должны принты идти так, что сначаля я должен увидеть в консоли вывод из скрипта, т.к. он первый напечатал, а потом уже из функции, т.к. она вызвалась позже и печатать в консоль позже должна, но не всегда именно так выходит! Поэтому было принято делать вывод в консоль только из одного места - только из самой DLL. Для всех! DLL сама изнутри туда пишет. Всё, что из скрипта идёт - через принт, который находится внутри DLL. Когда начал делать так, то всё стало работать синхронно в своей последовательности.
nikolz написал: Возможно не понял, но полагаю что Вы ошибаетесь.---------------------------Синхронизировать потоки надо при обращении их общим данным. -------------------------Четыре различных квика не имеют общих данных. Поэтому непонятно, что Вы пытаетесь синхронизировать.--------------------------DLL - это не данные а код.Не надо синхронизировать потоки при обращении к коду.-----------------------Не надо синхронизировать потоки при обращении к константам.--------------------- Смысл синхронизации в том, что в момент чтения данных одним потоком, второй их непредсказуемо изменит.
Да не поняли. Теорию знаю. По DLL тоже, и что и как там и в каком контексте работает, и переменные общие и т.п. Мне синхронизировать нужно работу вывода в консоль. Функции принтов есть в DLL и есть варианты, чтобы они разным цветом печатала в консоли есть функции и для скрипта - для захвата секции и много там ещё чего разного. Даже например внутри одного квика, допустим один поток колбэк выводит в консоль цветной текст - своим цветом последовательно по ходу работы функции принт за принтом. Далее этот поток прерывется и запускается другой поток, который тоже последовательно выводит в консоль своим цветом принт за принтом по ходу работы его функции. Что будет? Будет каша разноцветных принтов в перемешку, да ещё и цвета возможно сбиваться будут. Общие данные - захват консоли на время работы функций потока. Консоль и есть общий ресурс. Функции колбэка быстрые и захватывают консоль в начале функции и освобождают в конце, весь их вывод в консоль одним цветом получается, для каждого колбэка свой цвет, другой поток ждёт и не может ничего вывести пока колбэк не отработает полностью. Т.е. даже когда прерывается поток колбэка и запускается основной - это не страшно, основной кашу не сделает, ибо ждёт, потом возврат в колбэк и он продолжает свой цветной вывод своим тем же цветом. Отработал отпустил. Потом уже основной поток может продолжить и печатать своим цветом. У основного потока каждый принт - захват и освобождение консоли для своего цвета принта через захват секции(не в начале и в конце функции(как у колбэка) в которой принты основного потока - так можно бы было, но кое где логика не позволяет ибо ждёт результата колбэка и можно зависнуть, когда один захватит секцию и ждёт данных от колбэка, а колбэк не может захватить секцию, либо не логика, а просто нельзя тормозить надолго всю функцию основного потока по захвату консоли, ибо колбэки хрен тогда отработают, поэтому захват только на время работы одного принта основного потока). При таком построении каждый колбэк отписывает в консоль своим цветом даже если его прерывают, ну и основной поток спокойно себе печатает своими цветами и не пересекаются их выводы с выводами колбэка. Без этого такая каша, что даже выводы разных колбэков пересекаются, не что что с принтами основного потока и такое читать просто жопа.
nikolz написал: Прикольно, что недавно реализовал работу этих потоков без элементов ОС синхронизации.Работает существенно быстрее даже относительно Event.
nikolz написал: мьютексы излишне использовать, так как всего два потока.Ранее уже говорил, что это решается гораздо проще через Event.
Если рассматривать вариант использования только одного экземпляра квика, то да. Но вот у меня, например, на данный момент рабочих целых 4 варианта самостоятельных квиков. Все они используют в работе всегда одну и ту же DLL, которая обеспечивает мне консоль для вывода, ну и разные функции для работы с этой консолью, в том числе и цветной вывод. Для цветного вывода хош-не хош нужна синхронизация, иначе всё идёт в перемешку, хоть и разным цветом, что очень неудобно воспринимать, хотя и можно смириться с этим, но я решил не мириться. Так вот, коли 4 квика, то по сути это уже и 4 разных процесса. И поэтому либо мьютекс нужен, либо быстрая критическая секция. Но секция одна на разные процессы не пойдёт. Я выбрал для себя в реализации именно секции, но приходится хранить массив из секций (для каждого потока своя секция), которые инициализируются при подключении процесса в DLL. Сейчас всё работает как положено. Ну пришлось чуток добавить кода, но оно того стоит думаю.
Станислав написал: В скриптах используются всего 2 потока , один для колбэков и один в main.
В main для каждого скрипта создается отдельный поток, а вот колбэки находятся в некой очереди и вызываются синхронно, т.е. каждый колбэк ждет возвращения управления перед вызовом следующего.
Из-за этого имеем 2 особенности: 1. Нет нужды синхронизировать колбэки. 2. Надолго блокировать или производить тяжелые расчеты в колбэках не стоит, это приводит к подвисанию всех скриптов и даже терминала.
Если я ошибаюсь, поправьте.
немного поправлю. Для колбеков не создается специально новый поток. Колбеки вызываются в VMLua, которая создается в основном потоке терминала QUIK. --------------------------- Функция main запускается в отдельном потоке, в котором создается VMLua, дочерняя к VMLua колбеков.
Да похоже как-то так и есть. Факт только один - надо синхронизировать поток main() с потоком колбэков, кто бы его не запускал. Можно конечно поюзать всякие процесс мониторы и т.п., посмотреть процессы и их потоки, но и так понятно по вызовам стало, что main() и колбэки живут в разных потоках и что колбэки вызываются последовательно. Всем спасибо за ответы.
Станислав написал: В скриптах используются всего 2 потока , один для колбэков и один в main.
В main для каждого скрипта создается отдельный поток, а вот колбэки находятся в некой очереди и вызываются синхронно, т.е. каждый колбэк ждет возвращения управления перед вызовом следующего.
Из-за этого имеем 2 особенности: 1. Нет нужды синхронизировать колбэки. 2. Надолго блокировать или производить тяжелые расчеты в колбэках не стоит, это приводит к подвисанию всех скриптов и даже терминала.
Если я ошибаюсь, поправьте.
Да, потестирвал. Пришёл к такому же выводу. Колбэки вызываются последовательно все какие есть из всех запущенных скриптов. Синхронизация их между собой не нужна. main() и функции, которые она вызывает - это отдельный поток. Поток main() и поток колбэков синхронизирую между собой через критическую секцию в DLL. Сейчас всё отлично работает в пределах одного процесса. Далее сделаю либо через мьютексы для разных процессов, которые используют DLL, либо в DLL буду делать массив - открывать каждому процессу свою критическую секцию при подключении к DLL, чтобы каждый процесс использовал свою для своих потоков. И да, кто хочет так же использовать именно критические секции - не забывайте, что каждому процессу - своя секция и что сколько раз поток зашёл в секцию(а он может входить в неё последовательно подряд несколько раз без проблем), то столько же раз он должен потом из неё и выйти. У меня возникала странная ситуация - видимо когда вылетал по ошибке, не успел покинуть секцию поток колбэков, после этого при перезапуске скрипта функция из main() заходила и покидала секцию через вызов другой функции, потом в секцию заходил и покидал её поток колбэков и вот после этого поток main() уже зайти в секцию не мог. Звучит странно, ведь первый раз main() в секцию всё-таки заходил. При этом исключено, что поток колбэков где-то мог дополнительно не покинуть секцию. Понять долго не мог что не так работает. Тестировал и вставлял принты везде где только можно - везде вход - выход, а поток main() со второго раза зайти не может! После перезагрузки, когда нет вылетов всё заработало без проблем.
То, что колбэки могут приходить в разной последовательности(интересуют OnTrade, OnOrder, OnTransReply), а не в строго определённой это ещё ладно. Но вот было замечено, что работа одного колбэка может запросто прерываться, может начать выполняться другой колбэк или функция, вызываемая из main. Всё это приводит к тому, что в консоли получается каша из принтов от разных функций и колбэков. Сначла решил просто выводить принты от разных колбэков разным цветом в консоль- типа хоть как-то видно будет какой принт от кого, хоть и перемешаны они в консоли. Потом решил сделать так, чтобы пока не выполнится один колбэк полностью, другой колбэк не мог бы выводить принты в консоль. Внутри каждого колбэка в начале - вход в критическую секцию, в конце - выход из секции. Т.е. логика такая. Зашёл в колбэк - он сделал вход в секцию. Потом этот колбэк прерывается и квик запускает другой колбэк, который тоже пытается зайти в секцию, но не может, ибо она захвачена другим колбэком уже, т.е. он зайти не может, ждёт, пока секцию освободит первый колбэк и только потом продолжит своё управление. Но...вопрос: а дождётся ли он освобождения пока ждёт? Сможет ли квик пока тот ждёт прервать выполнение второго ожидающего колбэка и продолжить выполнение первого? Если да, то всё ОК. Первый освободит секцию, второй потом захватит её, отработает и завершится. Но не понятно как организована работа в квике по обработке колбэков. Толи в одном потоке, толи в разных, толи как-то по времени умудряется. Если в разных то проблем нет. Один поток тормознётся, пока другой отработает. Запускал простейший скрипт - выставит заявку, снять заявку. Вроде всё срабатывает и не зависает. Но может это пока просто потому, что именно так складывается и при прерывании одного колбэка другой просто не вызывается, а если вызовется, то зависнет. Может сталкивался кто с подобным или подскажет как вызываются колбэки квиком? А то зависнуть может же при определённых условиях. Иными словами вопрос такой: заход в колбэк, колбэк пытается войти в критическую секцию, она занята, он тормозится, ждёт освобождения секции, квик прервёт этот колбэк и запустит исполнение другого колбэка или функции, которые освободят критическую секцию, или зависнет?
До недавного времени индикативный курс пары USD/RUB можно было онлайн наблюдать в таблице ТТТ если вывести в эту таблицу индекс RTSI и смотреть на параметр "Курс". Он постоянно менялся во времени. Сейчас же этот курс стоит как вкопаный, потому что отображает он официальный курс ЦБ. Есть ли сейчас возможность как-то смотреть индикативный курс на межбанке на OTC?
Разве в документации сказано, что это поддерживается?
Я получал данные пакетами. Получаешь число записей, и в цикле запросы на очередной блок данных в 100 записей, больше не выдается.
В их документации не сказано, что это поддерживается, но также не сказано и то, что это не поддерживается! Сервер в ответе keep-alive отвечает, а значит поддержка на сервере есть, но только не в полном варианте. Единственное что я смог сделать, так это посылать по http запросы не в таком формате как обычно на один запрос: подключение -> запрос (Connection: close сразу в запросе) и так столько запросов сколько нужно, а так: подключение -> запрос(Connection: keep-alive) -> запрос(Connection: keep-alive) -> ... и т.д. ->запрос(Connection: close). То есть хотя бы так, что хоть позволяет одно соединение, а потом подряд несколько запросов и в последнем запросе указание закрыть соединение. А вот реальный HTTP pipelining почему-то не хочет делать. При нескольких GET запросах отвечает только на первый. По поводу блоков данных по 100 в цикле это понятно, это я знаю, но это по сути один запрос, вернее форма запроса одна, только start меняется как параметр и всё и гоняй в цикле, остальная основная часть URL-а постоянна, а я хотел реализовать в одном запросе сразу несколько запросов с разными URL-ами, но видимо их сервер такое не может обрабатывать, потому как так настроен.
Так же прошу поддержку ответить на следующее. Клиент QUIK соединяется с сервером QUIK у брокера, а сервер QUIK связан с мосбиржей и онлайн получает поток информации от неё, далее переправляя часть этой информации клиенту. Вопрос: как сервер QUIK получает информацию от биржи? По какому протоколу, API? Есть какие-то отдельные договорённости между брокером и биржей по передаче этой информации и в каком формате?
Alexander написал: После вечерней сессии сервер вернул уже другие комиссии. Поэтому почему только в течении сессии мне пока не понятно.
Конечно другие, ведь и комиссии за сделки тоже поменялись. Наверно, мосбиржа не хочет хранить или публично предоставлять историю комиссий.
Ну так и я о том же пишу. Сесиия идёт - сервер возвращает комиссии актуальные на сессю. Сессия завершилась - возвращает новые тоже актуальные. Всё как и должно быть. Я не понял почему только в течении сессии? Но не после сессии. После вечерней возвращает актуальные. Может после завершения вечерней сессии сервер не возвращает комиссии? Или как это понять? После вечерней я не пробовал.
funduk написал: Кстати, техподдержка Мосбиржи иногда на такие вопросы, заданные через форму обратной связи на их сайте, отвечает.
У меня был опыт работы по вопросам мосбирже. Написал им как-то раз вопросы по облигациям. Давно. Так и не дождался ответа от них вообще. Мысль написать им опять конечно возникала, напишу конечно скорее всего.
funduk написал: Alexander, ответ nikolz исчерпывающий. Если недостаточно - дальнейшие консультации платные
За наводку на API биржи спасибо. С запросами разобрался. Могу теперь сам формировать любые запросы по их документации. Нужные комиссии я уже получаю через запросы к собственной библиотеке на C++, которая делает http-запросы на сайт биржи. А вот вопросы к разработчикам остались. Вопрос же явно решился самостоятельно, почему нельзя квику транслировать в ТТТ комиссии? Что тут сложного? Зачем вот мне пришлось специально со всем этим разбираться, писать библиотеку? Да, я написал. Но время потрачено. Хотя надо признаться с пользой. И то хорошо. Но я вот не могу понять, неужели трудно в ТТТ транслировать эти комиссии? Всё равно же квик получает море информации с биржи. А в ней наверняка уже есть и комиссии. По поводу того, что: "У мосбиржи есть апи для получения этих комиссий в течение сессии (но не после сессии!)", то я пробовал получать комиссии до вечерней сессии и после. После вечерней сессии сервер вернул уже другие комиссии. Поэтому почему только в течении сессии мне пока не понятно. По этому поводу в доках мосбиржи есть такое:
Служебное поле SEQNUM в некоторых таблицах содержит уникальный номер обновления состояния таблицы. Его следует использовать в запросах для получения информации не с самого начала, а только обновления со времени, когда было получено предыдущее состояние таблицы. В ответах с инструментами, сделками и котировками присутствует блок dataversion. Поле SEQNUM в этом блоке содержит стартовый номер состояния таблицы для указанной версии. При увеличении значения версии поле SEQNUM изменяется, в том числе оно может быть уменьшено. Следует отслеживать данный параметр для корректной обработки переходов между торговыми днями, в случае если подключающаяся к серверу система активна круглосуточно.
В связи с тем, что возможности терминала QUIK ограничены и не позволяют даже получать некоторые параметры инструментов, которые транслирует Московская биржа и которые есть на сайте этой биржи, то возникла необходимость получать эти параметры самому через биржу. Элементарный пример - QUIK не транслирует комиссию за регистрацию сделки(бирж. + НКЦ) по инструментам ПФИ в ТТТ, или вместо настоящего кода инструмента по фьючерсу транслирует не код инструмента(underlying_asset), а транслирует в ТТТ - asset_code. Почему это не может реализовать сам QUIK это какая-то загадочная тайна. Просьбы решить это на стороне QIUK-а успехов не возымели. Поэтому пробую сейчас сам делать запросы на биржу через их web API. Для этого написана отдельная библиотека, которая делает нужные запросы согласно документации по API, которая есть на сайте биржи. Так вот простые одинарные запросы проходят без проблем и сервер выдаёт результаты. Сейчас пробую сделать http-запрос, в котором сразу несколько запросов(HTTP pipelining, заголовок с Connection: keep-alive). Сервер отвечает без ошибок(200 OK), но вот ответ даёт только на самый первый запрос, хотя ответе сервера присутствует в заголовке: Connection: keep-alive Кто-нибудь может пояснить почему ответ только один? Могу конечно реализовать последовательно несколько отдельных http-запросов, но хотелось бы решить проблему, тем более что сервер вроде как не ругается.
funduk, можете в 2-х словах рассказать как работает api от биржи? Просто не сталкивался с таким. dll библиотеки с описанием функций? Как их получить? Есть ли плата? Биржа даёт информацию миную брокера? Как к экселю прикрутить?
funduk написал: Alexander, два момента: Как минимум в БКС например биржевой сбор иногда транслируется неправильно после сделки (на одну копейку меньше или больше), что подтверждалось Мосбиржей в переписке. Этому багу как минимум год. У мосбиржи есть апи для получения этих комиссий в течение сессии (но не после сессии!). Я к экселю прикрутил.
1) Ну на 1 копейку лично для меня это вообще не принципиально. А вот то, что транслируется только уже после совершения сделки это уже принципиально плохо, т.к. я не могу прикинуть комиссию заранее по ПФИ. По акциям и облигациям обе комиссии(брокер + за регистрацию сделки) считаются легко. 2) Раз у Мосбиржи есть апи для получения этих комиссий, то кто мешает разработчикам квика комиссию по ПФИ транслировать в квик? Комиссия за 1 ПФИ(фьючерс, опцион) спокойно себе лежит и красуется на сайте биржи по любому ПФИ. Что мешает брокеру через апи получать эту комиссию и транслировать в ТТТ для инструмента ПФИ? На нужное количество ПФИ комиссию я уж как-нибудь посчитаю, умножив комиссию за 1 контракт на моё количество.
PS. В общем проблему решить можно. Прошу поддержку ответить. Так же можете зарегистрировать предложение. На данный момент я сам считаю комиссии за регистрацию сделки по ПФИ(бирж.+НКЦ) по формулам, которые взял с сайта мосбиржи. Проверял, сравнивал с комиссиями на сайте. Пока вроде всё сходится до копейки. Надеюсь, значит, что считает правильно. Но вот только расчёты громоздкие, коэффициентов много, они разные для разных случаев, тем более с апреля будут меняться, а это значит постоянно надо следить за изменениями, чтобы посчитать по одной формуле, надо сначала просчитать по другой громоздкой формуле и т.п. А можно просто транслировать данные в квик, которые биржа уже сама просчитала.
Так же мной обнаружено, что параметр "PREVPRICE" для FutPrice и PriceRub не подходит. Это параметр текущей расчётной цены, он меняется, т.е. он рассчитывается онлайн, а нужны именно расчётные цены клиринга. Подойдёт ли параметр "CLPRICE" для расчётных цен FutPrice и PriceRub? Он совпадает с ценой закрытия, и есть ли это расчётная цена клиринга, как описывает эти параметры мосбиржа?. И подойдёт ли параметр "CLPRICE" для Premium? Ведь "CLPRICE" это котировка клиринга, но соответствует ли она описанию параметра Premium, описанного на мосбирже не понятно, там вроде как речь идёт о теоретической цене, рассчитанной в клиринг. Это тоже самое или нет?
Повторно прошу поддержку ответить на вопросы выше. Мне фактически нужно либо, чтобы QUIK транслировал в ТТТ комиссию за регистрацию сделки(бирж.+НКЦ) по ПФИ-инструменту(есть на сайте биржи), либо подскажите как и где мне взять PriceRub и Premium, чтобы я сам смог посчитать.
Информацию по комиссии можно получить только в таблице "Сделки", соответственно после её совершения. Отдельная трансляция данных параметров не предусмотрена.Извините
1) Извините, а с чем связано, что: "Отдельная трансляция данных параметров не предусмотрена"? Кем конкретно не предусмотрена? Мосбиржей? Или программой QUIK? Какой смысл смотреть комиссию уже после совершения сделок? Оценка комиссий должна происходить ДО совершения сделок, тем более скриптом. Посчитать комиссию брокера не составляет труда. Например для акций общая комиссия считается легко: Vol * 0.0005(0.05% комиссия брокера) + 0.0003(0.03% биржа в случае тейк-заявки). Но как я узнаю комиссию биржи и НКЦ в случае фьючерсов или опционов? Ведь, что самое интересное - эта информация открытая. Она есть на сайте биржи. Меняется после расчёта каждый день и выкладывается биржей для любого ПФИ инструмента. В чём проблема транслировать как отдельный параметр данную комиссию в таблицу QUIK??? Для ПФИ легко считается только комиссия брокера, а вот комиссию биржи + НКЦ не мешало бы транслировать. Эта суммарная комиссия = const, не меняется за сессию, что нельзя её показать? По-моему проблема яйца выведенного не стоит. Реализуйте пожалуйста функционал. 2) На данный момент я пытаюсь сам рассчитать суммарную комиссию, считая отдельно комиссию биржи + комиссию НКЦ по формулам, которые даёт Мосбиржа для рассчёта. Формулы есть на сайте, так же они есть в отдельныйх файлах-документах(отдельно для биржи и отдельно для НКЦ - файлы .docx и .pdf соответственно), но там есть определённые нюансы, которые пока мне не понятны.
Поэтому возникли такие дополнительные вопросы: а) Значение FutPrice(Расчетная цена фьючерса, определенная в соответствии с Правилами торгов по итогам вечернего Расчетного периода последнего Торгового дня, предшествующего Торговому дню, в течение которого заключается Срочный контракт, в отношении которого осуществляется расчет биржевого сбора) для расчёта комиссий по фьючерсам, я вроде как могу взять из таблицы как параметр "PREVPRICE" для фьючерса. Прав ли я? Это тот параметр или нет? б) Значение PriceRub(расчетная цена базисного актива, определенная по итогам клиринговой сессии в соответствии с Методикой определения НКО НКЦ (АО) риск-параметров срочного рынка ПАО Московская Биржа) для расчёта комиссий по премиальным опционам, я вроде как могу взять из таблицы как параметр "PREVPRICE" базисного актива(например для SBER_CLT в случае опциона на акцию SBER). Прав ли я? Это тот параметр или нет? в) Но где мне взять значение Premium(значение Теоретической цены опциона, которое определено по итогам вчерашнего вечернего клиринга. Для опционов, заключенных в первый торговый день значение Premium равно значению Теоретической цены опциона) для расчёта как маржируемых, так и премиальных опционов через Lua-скрипт???
Касаемо вопроса в). В документе tarify-srochnogo-rynka.docx с сайта биржи для маржируемых опционов написано: "3.5.6. Справочная информация о применимых значениях Расчетных цен фьючерса (FutPrice) и теоретических цен опционов, а также об абсолютных величинах биржевого сбора, рассчитанных в соответствии пунктами 3.1 – 3.2 Тарифов (в российских рублях), публикуется на сайте Биржи не позднее Торгового дня, следующего за датой определения значения Расчетной цены для расчета цены фьючерса (FutPrice) / значения теоретической цены для расчета премии по опциону (Premium)." Надо заметить что в данном документе для премиальных опционов вообще не сказано ничего о том, что Premium где-то публикуется на сайте биржи. Так вот получается, что Premium я не вижу нигде, ни на сайте биржи в итогах торгов по инструменту(хотя говорят, что публикуют), ни в таблицах QUIK-а. Где мне его брать-то для расчёта?
Какой-то замкнутый круг получается. Помогите решить проблему по любому из вариантов(трансляции комиссии сразу в таблицу QUIK, либо как получить параметр Premium для самостоятельного расчёта), лучше по первому.
Здравствуйте. На сайте Московской биржи отображается Сбор за регистрацию сделки(Биржевой сбор и клиринговая комиссия) для опционов и фьючерсов. Просто ищем нужный инструмент и в Параметрах инструмента смотрим эту комиссию. Она меняется каждую новую сессию. Как я могу на скрипте Lua увидеть эту комиссию? В какой таблице? Какой параметр смотреть?
Столкнулся с такой же проблемой на ограничение в 200 окон. Брокеру по этому поводу пока не писал. Кто-нибудь обращался уже с подобной проблемой к своему брокеру? Было ли положительное решение вопроса со стороны брокера? Так-то 200 окон маловато. Хотя бы 300, фьючи и акции на них уже почти 200 штук, да в терминале всегда что-то ещё открыто.
С нашей стороны ограничения отсутствуют. Технически возможно работать двумя пользователями как и через один экземпляр программы (попеременно), так и с помощью двух экземпляров (в таком случае можно работать даже одновременно). Рекомендуем обратиться к брокеру за дополнительными комментариями.
У меня сейчас просто ТРИ QUIK-а от разных брокеров установлены и настроены. Неужели придётся ещё раз устанавливать для брокера, для которого QUIK уже установлен 1 раз?
Здравствуйте. Подскажите пожалуйста можно ли реализовать такую возможность. Установлен QUIK от брокера Открытие. Он настроен и работает как надо. Есть дополнительный аккаунт у этого же брокера Открытие на другого человека. Можно ли настроить QUIK, чтобы он работал хотя бы попеременно то с одним, то с другим аккаунтом? При входе вводим данные(логин, пароль) того аккаунта, который нужен и работаем.
PS: Что-то мне подсказывает, что скорее всего так не получится. Каждый QUIK имеет свой идентификатор и открытый/закрытый ключи в соответствующей папке и поэтому наверное придётся только устанавливать QUIK от Открытия второй раз, но в другую папку и ключи генерировать и у брокера регистрировать, если так можно конечно. Но хотелось бы использовать один экземпляр. Вобщем как сделать работу 2-х разных аккаунтов на 1-м компьютере от одного брокера через 1-н экземпляр программы? Если нельзя так, то можно ли так, как я описал выше с установкой в другую папку QUIK-а от того же брокера? От разных брокеров QUIK-и установлены в разные папки и работают на 1-м компе. А от одного и того же брокера можно так делать?
Какой версии проблемное Рабочее место QUIK? Также приложите, пожалуйста, скриншот окна настроек фильтра с раскрытым списком условий для фильтра.
Вы знаете, я сам не понял, как так, но абсолютно ничего не меняя через ~ 20-30 минут я опять попытался отформатировать столбец и..... как ни странно всё появилось, появились условия "больше", "меньше". Я точно знаю, что я абсолютно ничего не менял, я пытался найти настройки, от которых может быть зависело то, какие поля в таблице - строковые или числовые, но ничего подобного я не нашёл. Так что, я ничего не изменил нигде, но всё само собой заработало как надо. У меня стоит на 1-м компьютере 3 квика от разных брокеров, я сохраняю вкладки в файл у одного брокера в его квике и загружаю в квике другого брокера, возможно это как-то связано именно с этим. Вобщем сейчас всё работает как положено. Квик Открытия 10.2.3.7, квик Финама 10.3.6.3.
Возникла проблема! Установил квик от Финама. Загрузил в него вкладку, которая ранее была сохранена в квике от Открытия. Вкладка отлично загрузилась и всё отображается так как положено с учётом форматирования столбцов, сделанного в квике Открытия. Далее создаю в квике Финама новую ТТТ и хочу отформатировать столбец "% измен. закр", но с удивлением обнаруживаю, что в условиях форматирования нет "меньше", "больше", а вместо них есть другое, например "начинается с", "заканчивается на" и др. Я перехожу на загруженную мною ТТТ от Открытия в квике Финама и там делаю форматирование того же столбца "% измен. закр" и вижу, что там всё в порядке, т.е. там есть условия "больше", "меньше". Почитал документацию квика по форматированию и фильтрам и там написано, что если значения столбца числовые, то будут "меньше", "больше", а если строковые, то их не будет, а будут другие, что описал выше. Выходит, что ТТТ, сделанная в квике Открытия имела столбцы с числовыми значениями, а ТТТ сделанная в квике Финама имеет строковые значения. Ну и как мне теперь её форматировать если мне нужно "больше", "меньше" ??? Можно конечно попытаться создавать таблицы в квике Открытия, сохранять и загружать их в квик Финама, но это какое-то извращение. Если ли нормальные способ исправить ситуацию?
Владимир написал: У меня ОДИН ЕДИНСТВЕННЫЙ скрипт, который делает ВСЁ
У Вас скрипт узконаправленного действия - торговля акциями, фьючерсами. У меня скрипты на много чего. Все разом они не запускаются. Когда что-то надо, то запускаю, то что нужно. Я и опционы мониторю и торгую иногда. Даже есть визуализация в отдельных окнах(график, dll строит в отдельных потоках) стратегий набранных прямо с доски опционов(строится самостоятельно). Онлайн показывает график и движение фьючерса на нём отображается. Меняются цены - меняется график с опционной стратегией. Много чего разного есть.
Владимир написал: Alexander , Нафига брать данные из таблий КВИКА? ЕДИНСТВЕННЫЙ случай, когда мой скрипт берёт данные из таблицы Квика - клик правой кнопкой, чтобы определить, по какому именно тикеру кликнули, дабы вызвать соответствующее контекстное меню.
Как нафига? Скрипт берёт данные в основном либо из ТТТ, либо из стакана. Из своих собственных таблиц я данные не считываю, я их тута только вывожу.
Не ну вернее я тоже считываю только когда надо узнать куда мышкой щёлкнул для дальнейших действий.
Владимир написал: Alexander , Нафига брать данные из таблий КВИКА? ЕДИНСТВЕННЫЙ случай, когда мой скрипт берёт данные из таблицы Квика - клик правой кнопкой, чтобы определить, по какому именно тикеру кликнули, дабы вызвать соответствующее контекстное меню.
Как нафига? Скрипт берёт данные в основном либо из ТТТ, либо из стакана. Из своих собственных таблиц я данные не считываю, я их тута только вывожу.
Владимир написал: Alexander, А таблицы-то здесь каким боком? Это же только справочная информация для юзера. В моём скрипте даже "спящий режим" есть, когда таблица вообще не выводится. И что ещё за "немедленный выход из скрипта"?! Мой работает часами, днями, даже месяцами, и событий там как собак нерезаных. И при чём тут "внутрь main"? Я говорил про ПОТОК main. И уж точно ни одна таблица скрипту нафиг не нужна. Какие ещё могут быть "другие случаи"?
В информационные таблицы вывод информации после рассчётов некоторых данных берущихся из таблиц квика в реальном времени. Мне нужны эти рассчётные данные онлайн для моего анализа. Немедленный выход не из скрипта, а из цикла в той же функции. Выход нужен для робота того же по условию. Если ни одна таблица скрипту во вашему не нужна, то тогда прошу ответить зачем в вашем скрипте есть таблица? Я предпочитаю те же сделки отображать в таблице, не только в файл всё писать. Есть например простой скрипт - щёлкнул по таблице - купил, щёлкнул - продал, сделка отобразилась. У меня разные всякие есть скрипты. Некоторые следят, некоторые позволяют определённую позицию например брать - продавать(покупка базы + продажа фьючерс например за раз), а решение для этого я могу принимать по другой таблице, в ней считается, данные из стакана берутся лучшие, выводится что мне надо. Короче, смотря что мне надо, то и использую. Ваш скрипт единственный он вообще что делает? Акциями торгует? Явно вроде не робот внутридневка.
Владимир написал: SetCell работает вполне прилично. Раз в две секунды я переписываю всю таблицу, всё происходит довольно быстро.
У меня есть таблицы, там тоже раз в секунду обновление. Но это просто информационные таблицы с кое-какими рассчётами для анализа и там всё работает как положено. Но кое где такие задержки просто не приемлемы. При возникновении события нужен немедленный выход из скрипта без всяких задержек, либо само событие произойдёт как раз во время задержки, что тоже не приемлемо, так как не выйти пока в задержке. Поэтому SetCell прилично работает в информационных таблицах, но совершенно не приемлемо в других случаях. Раз SetCell не даёт гарантии 100%-ного обновления таблицы после его вызова - лично для меня это абсолютно не приемлемая работа данной функции. Не знаю, как повлияет на работу SetCell перенос всего в main(), может и станет работать как надо, но у меня всё построено на вызовах функций и всё переносить внутрь main() для меня лично это не подходит, так как запутывает всё, никакой читабельности, всё в одной куче - не вариант для меня.
А ведь ещё, что интересно? Что вызов главного рисовальщика WM_PAINT, который собственно и рисует в буфер окна и после которого апдейт содержимого из него автоматом после EndPaint не приводит к обновлению окна! А вот обработчик WM_SIZE обновляет. Значит он игнорирует изменение буфера окна не понятно по каким причинам. А такие события как изменение размера окна(вызов виндой WM_SIZE) это делают.
Nikolay написал: Вы говорите что нет проблем, у меня же тот же скрипт на чистом демо квике выдает обратное. Себе я верю больше.
Вот в том и дело, что nikolz думает, что раз у него работает, значит и у всех работать будет. Это не так. От чего там и когда идёт апдейт? Может даже зависит от количества других окон, от выводимой информации в окне и мало ещё от чего. Главное это то, что вызов SetCell абсолютно не гарантирует физический вывод в окно. Только куда-то там внутри окружения чего-то. Гарантировано апдейт всего окна делает обработчик WM_SIZE в оконной процедуре окна, что уже доказано.
Вот с утра скрипты работают. Один не обновлял ячейку, когда в диапазоне, сейчас обновляет нормально. Количество выводимой информации в другие ячейки изменилось, сейчас её стало больше. Как это связано знают только разработчики.
Но похоже заниматься этим не будут. Хотя интересно. Сам квик иногда просит обновиться. Значит работают. Чего-то там делают, меняют. Что тогда меняют и для чего? Казалось бы вот и надо с каждым новым обновлением исправлять то, что уже накопилось. Но нет. Что тогда обновляют?
Как SetCell работает это тайна. Но как можно было бы попробовать сделать. SetCell выводит данные сразу, без промежуточного хранения, в нужную часть буфера окна(DrawText, TextOut). Видимая часть окна разбивается на регионы. Если часть буфера окна под вывод данной ячейки в видимой части окна, то InvalidateRect в самом конце SetCell для региона окна для этой ячейки. Как-то так.
Владимир написал: Вы можете здесь плакаться в жилетку сколько угодно, но это Ваши, И ТОЛЬКО ВАШИ проблемы!
Получается проблемы мы решаем только общаясь здесь между собой. А как же тогда достучаться до поддержки? Они же сайт этот сделали для чего-то? Чтобы в нём не участвовать?
nikolz написал: Посмотрите Выше мое сообщение от 29.12.2022 20:34:14 относительно Вашего теста.
Посмотрел. Я же писал, что пробовал варианты с последним параметром в SetCell и Highlight - ом экспериментировал. Толку нет. В некотрых скриптах помогает, в некоторых нет. Это первое, что я делал. Да что толку-то. Ну исправит на раз, на другой раз не поможет. Проблему надо решать на стороне квика. Как я понимаю в реализации SetCell разрабы не хотят после каждого её вызова делать апдейт всего окна, что в принципе логично. Могли бы обновлять регион окна, где ячейка, но видимо и по этому пути идти не хотят или не умеют. Как именно реализована работа SetCell у них я не знаю. Я вижу только одно, что если ты сделал вызов SetCell, то нет никакой гарантии, что вызов функции приведёт к реальному обновлению части окна, ответственного за эту ячейку, не говоря уже про всё окно. В этом случае со стороны разработчиков возможно было бы просто делать апдейт всего окна целиком по таймеру, но они и этого делать не хотят. Они тупо как-то накапливают изменения видимо не от одного SetCell - а, а от нескольких и по какому-то только им известному алгоритму в какой-то только им известный момент делают апдейт и видимо всего окна таблицы сразу. Если бы работа каждого SеCell - а приводила бы только к обновлению региона окна где ячейка, думаю всё работало бы без проблем, и не надо было бы обновлять всё окно. Но для этого нужен алгоритм, которого у них нет. Этот алгоритм у них работает по ихнему и явно не лучшим образом. Тут со стороны разработчиков требуется работать на уровне оконных API виндовс.