Честный способ увеличения риска ММ советника со стороны ДЦ и возможность борьбы с этим средствами MQL4 - страница 3

Вам привел простой пример нелогичности ваших утверждений, что ДЦ что-то должно вернуть.

Речь ни о том, что кто-то в чем-то виноват. Если хотите, чтобы всегда соблюдался ваш ММ, то необходимо учитывать у себя в советнике возможность подобной ситуации. Иначе есть риск превышения вашим советником заложенного вами ММ.

Под словом "вернуть" я имелл ввиду вернуть ситуацию - депо(эквити), может быть позы(на усмотрение ДЦ) - которая была до этого ошибочного перечисления. Обычно всякие спорные моменты с ДЦ решались именно так....))))

Именно так вас и понял с самого начала.

Никогда не использую на реале автоматический расчёт лота.

Корректирую его редко ступенчато руками по мере роста депозита.

Т.е. пока например, депо не вырос на 20-30%%, лот остаётся изначально заданным.

Чем больше всего автоматизировано, тем больше шансов что что-то откажет.

Едва ли что-то настолько же опасно как неправильно выбранный лот.

А причин, по которым он может рассчитаться некорректно, много.

Тут лучше недобрать профита, чем перебрать убытка.

Не надо передергивать. Да, - надо радоваться фортуне. Если будет профит, - то это уже будет забота ДЦ, а не трейдера.

Тогда сотрудники ДЦ должны будут доказывать ситуацию.

Учитывать нельзя.

Начисления/списания производятся с помощью ордера с численным значением типа, равным 6.

Документированные типы ордеров имеют численные значения от 0 до 5.

Функция OrderProfit() для такого ордера даёт величину начисления/списания, но полагаться на это нельзя.

Можно поподробнее?

Т.е. это ордера, я взглянул в "История счета", имеющие в поле "Тип" значение "Balance". Этому и соответствует 6?

И почему нельзя на это полагаться?

Кухни становятся все более изобретательны. Расширяется практика снижения плеча (увеличение маржинальных требований) в выходные на порядок-другой. Прекрасный способ вынести лузера с рынка на полностью законных основаниях по м-колу.

О каком ММ можно говорить в таких условиях :( ... Как это можно учесть в ТС, пусть даже самой гениальной?

Эт-точно.

Уже почти у всех в кухонь в Регламентах прописаны причины, по которым отклоняются претензии. Среди прочего: использование сослагательного наклонения :)

Да, имеющие в поле "Тип" значение "Balance". Но советник должен пользоваться предоставленным API.

Вот тестовый скрипт:

#include <stdlib.mqh>

string type_name(int type)
{
  switch(type)
  {
    case OP_BUY:
      return("OP_BUY");
    case OP_BUYLIMIT:
      return("OP_BUYLIMIT");
    case OP_BUYSTOP:
      return("OP_BUYSTOP");
    case OP_SELL:
      return("OP_SELL");
    case OP_SELLLIMIT:
      return("OP_SELLLIMIT");
    case OP_SELLSTOP:
      return("OP_SELLSTOP");
    default:
      return("Unknown type: " + type);
  }
}

int start()
{
  int i;
  int hTotal = OrdersHistoryTotal();

  for(i = 0; i < hTotal; i++)
  {
    if(OrderSelect(i, SELECT_BY_POS, MODE_HISTORY))
    {
      if(OrderTicket() == AAAAAAAA || OrderTicket() == BBBBBBBB ||
         OrderTicket() == CCCCCCCC || OrderTicket() == DDDDDDDD)
      {
        Print("OrderOpenPrice = ", OrderOpenPrice(),
              ", OrderClosePrice = ", OrderClosePrice(),
              ", OrderType = ", type_name(OrderType()),
              ", OrderProfit = ", OrderProfit());
      }
    }
    else
      Print("Error: ", ErrorDescription(GetLastError()));
  }

  return(0);
}

Пополнение/снятие выглядит как ордер. В данном коде скрипта нужно заменить AAAAAAAA, BBBBBBBB, CCCCCCCC и DDDDDDDD на номера ордеров, в том числе ордеров, соответствующих пополнению/снятию.

Лог с закладки "Эксперты" (открытый извне, то есть, строки - в прямом, а не обратном порядке) выглядит примерно так:

OrderOpenPrice = 0, OrderClosePrice = 0, OrderType = Unknown type: 6, OrderProfit = 10000
OrderOpenPrice = 0.6279, OrderClosePrice = 0.627, OrderType = OP_SELL, OrderProfit = 9
OrderOpenPrice = 0.6486, OrderClosePrice = 0.655, OrderType = OP_BUY, OrderProfit = 108.8
OrderOpenPrice = 0, OrderClosePrice = 0, OrderType = Unknown type: 6, OrderProfit = -500

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

В документации описаны 6 типов ордеров, и функция type_name() полностью покрывает всё их множество. Однако, мы видим в логе "OrderType = Unknown type: 6".

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

В этом случае даже не к чему апеллировать. Поэтому учесть "левые" начисления/списания нельзя.