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

Nektodron, а можно всё-таки добавить в NewOrder аргумент string validity >Период действия приказа, чтобы пользователь сам мог выбирать, что ему необходимо DAY или GTC (с описанием в примере DAY (по умолчанию) и прописанной выше возможной проблемой). Уровень осознанию людей доросших до использования API, думаю, достаточно высок, чтобы применять необходимый/оправданный метод.
Использование DAY, на сколько помню, не позволяет переносить Стоп по контрактам, даже, через дневной клиринг.
Во всём остальном касающемся API предоставлен полный полёт фантазии с возможными ошибками ложащимися на плечи экспериментатора, а здесь безальтернативность, родительская опека.

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

Я использую ордера.
Такой вопрос. У меня 1 счёт, 1 инструмент, но 2 скрипта (допустим).
И допустим один в лонге, другой в шорте. Такое возможно ? Ведь моя позиция тогда ведь = 0..

это моё 100-е сообщение !

Если вы используете выставление заявок через ISecurityRT, то вы сами контролируете позицию, так что все зависит от вашего же алгоритма.
Если вы используете позиции, то такое возможно.

Будет ли правильной цена входа, полученная так:Интересует, будет ли она одной и той же до клиринга и после

На мой вопрос имеется ответ ?

должна быть одна, если ничего больше не выставлялось

А как получить цену открытия текущего бара ? При пересчете "Интервал" это можно ?

Просто ордер у меня выставляется при открытии свечи.
А сразу после этого (на этой же свече) должен ставиться стоп, считая от цены открытия свечи.
Допустим свеча открылась по 100. Ордер исполнился по 100.01.
Потом я получаю последнюю цену (sourceRt.FinInfo.LastPrice) и ставлю стоп. Получается стоп = 100.02 (уже) - 1 = 99.02 (а должен быть = 99)

Включите режим "итервал+сделка", последний бар будет содержать цену открытия текущего бара.

Спасибо. Ещё вопросик.

Если у меня sourceRt.BalanceQuantity == 0, то снимаются стопы. Это логично (зачем они нужны то).

Но бывают и такие случаи:

.

Видимо скрипт увидел (а может и нет) что sourceRt.BalanceQuantity == 0 и как-то (при потерянной связи) снял условные заявки. Вот сейчас в 10:00 он подключится, а стопов уже не будет. Вот так..

Может есть какая-нибудь возможность проверять статус соединения ?

Дополнение: хм, заявки висят. А что он тогда пишет что они отменены?

По поводу снятых заявок непонятно, можно прислать лог?

Пришли логи ?

И ещё один вопросик.

Как получить текущее значение RecalcInterval (TSLab.DataModel.GraphViewDataOptions.RecalcInterval) ?

Из API никак, не было задумано.

Нет. На какой адрес посылали? надо на contact@tslab.ru

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

Спасибо.
Да, они остались активными. Но когда я в 8:00 взглянул в программу, то я подумал что "всё пропало !"...

Здравствуйте. Я опять насчёт проскальзывания и NewOrder().
Мне почему-то кажется, что оно вовсе не в шагах цены или процентах, а просто в пунктах.
А ещё мне кажется, что заявка отсылается по цене "цена + это_проскальзывание".

Я прав ?
У меня Финам

NewOrder - две функции. Если имеется в виду та, где проскальзывание задается вручную, то да - проскальзывание в пунктах (это логическая ошибка, хотелось сделать в шагах цены). В Процентах там не предусмотрено.
Если используется функция с дефолтным проскальзыванием (из настроек скрипта), то там проскальзывание в шагах и процентах.
Что касается цены заявки. Если выставляете лимитную, то так и есть - просклаьзывание сразу прибавляется. Собственно для лимитной заявки проскльзывание вещь абсолютно бессмысленная.
Проскальзывание используется для условных заявок. В этом случае, цена условия равна цене заявки, а цена лимитной заявки, после срабатывания условия, равна цена+проскальзывание.
Сам TSLab при работе с позициями не использует проскальзывание для лимитных заявок (они неявно выставляются через опции работы скрипта).