В примерах стратегий часто можно видеть такие конструкции:

Position p = BuyAtLimit(bar + 1, Close[bar]);
if (p != null)
{
 SellAtLimit(bar + 1, p, p.EntryPrice + DEVIATION1);
 SellAtStop(bar + 1, p, p.EntryPrice - DEVIATION2);
}

Такой код работает на истории, правда есть нюанс - что если цена внутри бара меняется в другом порядке, сначала реализуется цена для выхода, а потом для входа? Но этот пост о другом, как реализовать этот код в стратегии для реальной торговли?

В квике есть заявки типа с условием «по исполнению».

Заявки «по исполнению» представляют собой условные заявки, условием активации (начала проверки их стоп-цены сервером QUIK) которых является исполнение определенной активной заявки (далее называемой «заявкой-условием»). Такие заявки могут применяться, например, для закрытия позиции по инструменту, открываемой данной активной заявкой.

Исполнение одной активной заявки может вызывать активацию нескольких заявок «по исполнению» разных типов.

Как выставить такие заявки в Квик при торговле через наш адаптер можно прочитать в разделе Community.

Position p = LastPosition;

if(!SellAtStop(bar+1, p, stopPrice)) SellAtLimit(bar+1, p, limPrice);

На истории такая конструкция - заглядывание в будущее, если сначала проверять стоп, а затем торговать лимит - на больших движениях в первую очередь будет фиксироваться убыток, если переставить методы SellAtStop и SellAtLimit в прмере местами - то будет фиксироваться прибыль, если бар пробил и уровень stopPrice и уровень limPrice.

В реальности, чтобы проверить оба уровня на каком-то временном интервале(наприер с 10:00 до 10:10) надо выставить 2 заявки в квик, и ждать какая из них сработает. Желательно после срабатывания первой отменить вторую, т.к. иначе они обе могут сработать. Для этого в квике есть заявки «Со связанной заявкой».

Из хелпа квика:

«Со связанной заявкой» – это две заявки по одному и тому же инструменту, одинаковые по направленности и объему. Первая заявка типа «Стоп-лимит», вторая – лимитированная заявка. При исполнении одной из заявок вторая снимается. Этот тип поручений также называют «O.C.O.» (one cancel other, «одна заявка отменяет другую»).

Как использовать их в торговле через наш адаптер? Читайте в разделе Community.

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

В классе-наследнике определяем конструктор по умолчанию, который передает конкретные параметры в базовый. Вся торговая логика уже реализована. Пример:

namespace WLRT.Strategyes
{
    public abstract class MyBaseStrategy : WealthLab.WealthScript
    {
        private readonly double _koeff;

        protected MyBaseStrategy(double k)
        {
            _koeff = k;
        }

        protected override sealed Execute()
        {
            if(_koeff==0) DoSmth();
            else DoSmthElse();
        }
    }

    public sealed class MyStrategy1 : MyBaseStrategy
    {
        public MyStrategy1() : base(1)
        {
        }
    }
}

Существует целая индустрия по хостингу виртуальных машин. Стоимость варьируется, но обычно приемлемая по мощности машина стоит 800-1000р в месяц. Если вы хотите стабильно торговать - вынесите свою торговую часть на сервер в интернете, а свой интернет канал используйте для контроля.