Imersio Arrigo написал: "блокируйте мне торговлю, если мой дневной убыток составил 10%"?
К сожалению CoLibri не умеет блокировать торговлю пользователей. Только если брокер будет это делать в ручном режиме. В общем, нужно с ним договариваться.
Imersio Arrigo написал: А речь про то, чтобы изначально ограничить убытки, не дать ему довести дело до маржиколов.
Это тоже есть в CoLibri
Приведите пример использования конечным клиентом, и задания ограничений по соглашению с брокером? А то с вашего описания, это, мягко говоря, не очевидно
Не совсем понятно какого примера Вы ожидаете. Клиент звонит/пишет брокеру, говорит что хочет, а брокер настраивает.
swerg написал: Может в этом окне вообще есть смысл сделать этакий лог скриптов? <время> скрипт такой-то - started <время> скрипт такой-то - завершился с таким-то результатом и потому-то
Будет какая-то польза с этого окна.
Ну и СДЕЛАТЬ ЕГО МАСШТАБИРУЕМЫМ по размерам уже!!
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Владимир Б****ов написал: 1. Какие варианты снятия существуют: 1-перебор таблицы заявок, 2-снятие по ["ORDER_KEY"], 3-какие еще?
Снять заявку через LUA можно только по номеру заявки. Как его узнать уже другой вопрос.
Цитата
Владимир Б****ов написал: 2. не могу найти описание ВСЕХ полей таблицы Transaction, в одних примерах нет поля ["ORDER_KEY"], в других оно есть
См документацию на терминал, "Раздел 6. Совместная работа с другими приложениями" - "Импорт транзакций" "Формат .tri-файла с параметрами транзакций"
Цитата
Владимир Б****ов написал: 3 при выставлении определенных видов заявок, требуется заполнение полей, которые лишены смысла при таком типе заявки и эти поля не помечены как "обязательные"
Этот пункт совершенно непонятен.
Цитата
Владимир Б****ов написал: Если я устанавливаю ['ACTION'] = "KILL_ORDER", то такие поля как OPERATION, TYPE, QUANTITY, PRICE (может и другие) вообще теряют смысл? Важно только поле ORDER_KEY - номер снимаемой заявки(если я правильно понимаю назначение этого поля), или и другие поля необходимо заполнять?.
Согласно нашей документации, в транзакции "KILL_ORDER" должны быть следующие поля: CLASSCODE, SECCODE, TRANS_ID, ACTION, ORDER_KEY Если в других источниках написано как-то иначе, это вопрос к автору этих источников.
Цитата
Владимир Б****ов написал: но хотелось бы видеть примеры реализации простейших вещей: выставление заявок
См документацию на терминал, "Раздел 6. Совместная работа с другими приложениями" - "Импорт транзакций" "Формат .tri-файла с параметрами транзакций" - "Примеры строк, которые могут содержаться в файле" Единственное синтаксис нужно использовать LUA
Цитата
Владимир Б****ов написал: Вопрос: Если OnTransReply не дойдет, то как узнать номер заявки, которая была выставлена по транзакции TRANS_ID?
По таблице заявок.
Цитата
Владимир Б****ов написал: Чем дальше в лес, тем ...... В функции OnOrder(order) в таблице order есть
trans_id
NUMBER
Идентификатор транзакции
Это номер транзакции, отправленный в sendTransaction?
trans_id в таблице заявок это тоже самое что trans_id в транзакции
Imersio Arrigo написал: Например модуль для квика, неотключаемый вручную, и управляемый брокером, который следит за операциями и рисками. Настройки модуля прописываются в договоре с брокером, и изменяются либо в ЛК, либо личным визитом к брокеру.
Если Вы хотите просто пожелание на доработку, для этого не обязательно разводить эту дискуссию, достаточно просто сформулировать мысль в соответствующей ветке форума.
Еще раз, Вы говорите о ситуации которой не должно быть, а если она и возникнет то это будет ошибкой в ядре биржи. Биржа - первоисточник, а значит эталон и если эталон оказался кривым это значит что все пропало. И QUIK в этом месте не тот прибор который от этого должен защитить. А защитить должна сама биржа.
тот самый написал: т.е. судя по Вашим словам...достаточно всего лишь одной пропущенной сделки, чтоб весь техОнализ по данному графику и эмитенту - пошёл лесом? Причём... на неопределённый срок???
Да именно. Осталось только выяснить у биржи на сколько этот сценарий вообще возможен.
тот самый написал: Что значит перестанет показывать дальше пропущенной - он, что? удалит уже нарисованные свечки? или "дальше пропущенной" - означает, что просто "забьёт" причём, на НЕопределённый срок на этот график??????
Дальше момента времени в который появится "плохая сделка" (а не времени сделки) график не будет отображаться. При этом в таблице обезличенных сделок данные по прежнему будут появляться.
Цитата
тот самый написал: Когда в таком случае, он опять начнёт отображение графика по эмитенту? Шо? Опять после Ваше "Перезаказать архив графиков/Очистить всё и начать новый сиЯнс"? Так чо ли?...
На следующий день история "проблемного" дня, если ничего не исправить, также будет отображать только кусок. А текущий день будет отображаться нормально. Если конечно такая ситуация вообще возможна, о чем нам не известно.
тот самый написал: Вы готовы в случае доказательства, что на МОЁМ компьютере - ЭТО приведёт к снижению быстродействия - купить мне новый компьютер?.....))
Как уже было сказано и еще раз повторим
Цитата
Sergey Gorokhov написал: Если Вы найдете на ошибку, это будет даже хорошо, мы ее исправим.
Sergey Gorokhov написал: целиком и полностью полагаемся на биржу.
т.е. тем самым, вы только что признали, что возможна ситуация получения данных "из прошлого"? И более того, как в таком случае - поведёт себя квик и его отображение графика по данной пропущенной сделки?
если биржа пришлет сделку из прошлого это будет форс мажор который означает ошибку в ядре биржи.
тот самый написал: тут не ошибка, а просто Ваш подход к ситуации - выше вам я конкретно на пальцах привёл почему будет снижение быстродействия - вы же - начали меня троллить...)))
Да, но это не "факты" а предположения которые не являются действительностью. Конечно, любой фильтр/форматирование как-то нагружает процессор, это неоспоримо, но делать выводы о проблемах с быстродействием, не корректно. Тем более не имея этих самых "проблем".
Цитата
тот самый написал: Если я не прав в своём сужджении и алгоритм поиска и выделения ячейки - другой - приведите факты....)))
факт уже был приведен.
Цитата
Sergey Gorokhov написал: Странно а условное форматирование, почему-то не приводит к "удару по быстродействию QUIK-а"
Sergey Gorokhov написал: Сразу следует отметить что в данном случае речь про данные от одного рынка.
значит ли это, что происходит предварительная сортировка на стороне сервера или вы в плане последовательности - целиком и полностью полагаетесь на биржу??
Sergey Gorokhov написал: Это галка для таблицы истории
а где об этом написано в документации???
из документации:
Данное свойство необходимо, если используется Таблица истории (либо в графиках используются параметры из Таблицы истории) либо Таблица изменений значений параметров.
тот самый написал: с удовольствием выслушаю, как и главное, почему - не верно...)))
Таблица обезличенных сделок едет одним сплошным потоком. Вставка "посередине" в ней в принципе невозможна. Сразу следует отметить что в данном случае речь про данные от одного рынка. На разных рынках время может быть не синхронизированным и может создасться впечатление будто сделка пришла из прошлого, но это иллюзия.
тот самый написал: при этом, если после того, как свеча была закрыта - придёт отставшая сделка (попадающая по своему времени в закрытую свечу) - закрытая свеча, скорей всего - будет "перерисована". Если, описанное мной так и есть - прошу включить это в документацию.
Категорически не верно. Сделка не может придти из прошлого. Если сейчас пришла сделка, то до нее сделка придти уже никак не сможет.
Идентификатор, это строка. А Вы указываете переменную. N1=getNumCandles(MVAs)
Соответственно, либо у этой переменной должно быть строковое значение в виде идентификатора, дибо ошибка в коде и должно быть написано в кавычках: N1=getNumCandles("MVAs")
Космонавт написал: Сергей, спасибо за ответ. Но тогда все индикаторы придётся считать самостоятельно в коде (если DataStore). А это отнимает вычислительные мощности.
Ваш робот, Вам решать как его реализовать оптимальнее.
Здравствуйте, getCandlesByIndex - получает данные по запросу. CreateDataSource - получает данные по мере появления. Таким образом, на CreateDataSource тратится меньше времени. Касаемо экономии ресурсов, тут все зависит от робота. То есть Вам самостоятельно нужно определить что ест больше.
room72, У Вас в коде идентификатор указан как "NENADO" Проверьте свойства нужного Вам графика (а не первого попавшегося), вкладка Дополнительно, в поле Идентификатор, чтобы было указано тоже самое.
Проблема точно либо в переменных Date, Time либо в идентификаторе. Если не можете самостоятельно найти ошибку, выложите скриншоты на которых будет видно свойства графика (там где идентификатор) и содержимое в отладчике (так чтобы было видно результат в переменной Slice)
Здравствуйте, Проверьте в отладчика, какая дата/время в переменных Date, Time а затем, посмотрите есть ли на графике свеча с таким Date, Time. И еще проверьте чтобы идентификатор был корректно указан.
тот самый написал: и где её брать? из какой таблицы и какой у ней формальный параметр?
Читаем документацию: Для спот-рынка – соответствует значению параметра «Цена приобретения» в таблице лимитов по бумагам. Для срочного рынка – соответствует значению параметра «Эффект. цена поз.» в таблице позиций по клиентским счетам
Sergey Gorokhov написал: Раздел 3. Просмотр информации - Состояние счета
То есть открытые позиции по фондовому рынку я через LUA получить смогу + доступные денежные средства. И зная всё это уже самому подсчитать итоговую балансовую стоимость всего счета?
Не понятно какой ответ ожидается. Вам уже было сказано что расчет параметров можно воспроизвести.