Características da linguagem mql5, subtilezas e técnicas - página 173

Novo comentário
 
fxsaber:

Actualizado acima.

Fórum sobre comércio, sistemas automatizados de comércio e teste de estratégias comerciais

Peculiaridades de mql5, dicas e truques

fxsaber, 2020.04.09 13:13

Parece que não o encontrou de todo. Dê uma vista de olhos na Documentação. Há dois volumes por encomenda.

Estes são limitadores vivos. O primeiro número é o volume original, o segundo é o volume vertido. Assim que se tornam iguais ou são eliminados, entra na história.


Essa não é uma ordem executada em duas partes? Parece estranho que os volumes não executados sejam os mesmos.

 
Alexey Viktorov:

Essa não é uma ordem executada em duas partes? É uma estranha coincidência que os volumes não executados sejam os mesmos.

Uma coincidência. Têm até mags diferentes.

 
fxsaber:

Não pode haver ordem no modo de ordem quando está vivo. Quando morto - haverá um tempo de primeira execução, como foi dito originalmente.


Encontrado na história.

 
fxsaber:

Quando se desmorona via CloseBy, parece perder as majestades. Necessidade de verificar.

Esta parece ser a razão pela qual o primeiro código abaixo não vai funcionar.

Fórum sobre comércio, sistemas comerciais automatizados e teste de estratégias comerciais

Lucro histórico na MQL5 ?

fxsaber, 2017.08.26 19:16

  1. MQL5 
    double Profit( void )
{
 double Res = 0;

 if (HistorySelect(0, INT_MAX))
   for (int i = HistoryDealsTotal() - 1; i >= 0; i--)
   {
     const ulong Ticket = HistoryDealGetTicket(i);
     
     if((HistoryDealGetInteger(Ticket, DEAL_MAGIC) == MagicNumber) && (HistoryDealGetString(Ticket, DEAL_SYMBOL) == Symbol()))
       Res += HistoryDealGetDouble(Ticket, DEAL_PROFIT);
   }
     
  return(Res);
}


  2. MQL5 + MQL4 
    #include <MT4Orders.mqh> // https://www.mql5.com/ru/code/16006

double Profit( void )
{
 double Res = 0;

 for (int i = OrdersHistoryTotal() - 1; i >= 0; i--)
   if(OrderSelect(i, SELECT_BY_POS, MODE_HISTORY) && (OrderMagicNumber() == MagicNumber) && (OrderSymbol() == Symbol()))
     Res += OrderProfit();
     
  return(Res);
}

Contar o lucro por magia parece ser um problema.

 
Os preços de encomenda são normalizados, os negócios não. O guião encontra tais acordos.
void OnStart()
{
  if (HistorySelect(0, INT_MAX))
    for (int i = HistoryDealsTotal() - 1; i >= 0; i--) // Перебираем все сделки
    {
      const ulong Ticket = HistoryDealGetTicket(i); // Тикет сделки
      const double Price = HistoryDealGetDouble(Ticket, DEAL_PRICE); // Цена сделки
      
      if (NormalizeDouble(Price, 5) != Price) // Если цена сделки не нормализована,      
        Print(Ticket);                        // печатаем тикет сделки.
    }
}
 

As setas para abrir/fechar posições, que o MT5 coloca automaticamente em tempo real, são baseadas em eventos TradeTransaction.


Ainda agora vi que estes eventos (abrir e fechar cerca de uma dúzia de posições) não chegaram ao terminal devido a uma falha momentânea na ligação - foi uma coincidência tão grande que eu estava sentado no meu PC e olhava-os de frente. Como resultado, não há setas correspondentes.


E, como já aqui foi dito por vezes, não se pode confiar na OnTradeTransaction em EAs de combate. É uma pena que não exista um mecanismo público fiável para lidar com a OrderSendAsync.

 
fxsaber:

É pena que não exista um mecanismo público fiável para lidar com a OrderSendAsync.

podem os serviços aceder aos ofícios? - se assim for, então é possível monitorizar a cada 10 ms e enviar o evento para o gráfico

olhei para a ajuda, pensei que talvez tivesse os serviços acrescentados, mas penso que foi assim o ano passado:

-É um programa que, ao contrário dos indicadores, dos Conselheiros Especialistas e dos guiões, não requer a ligação a um gráfico. À semelhança dos guiões, os serviços não tratam de quaisquer eventos, excepto no caso do evento de lançamento. A fim de iniciar um serviço, o seu código deve conter a função OnStart handler. Os serviços não aceitam quaisquer outros eventos excepto Start, mas podem enviar eventos personalizados para os próprios gráficos usando EventChartCustom

UPD: Escrevi um guião de serviço.

struct SOrderInfo
{
   int positionstotal;
   int orderstotal;
   int historyorderstotal;
   bool operator==(const SOrderInfo &v){return(positionstotal==v.positionstotal && orderstotal==v.orderstotal && historyorderstotal==v.historyorderstotal);}
};
//+------------------------------------------------------------------+
int OnStart()
{
   SOrderInfo CurrState = UpdateOrdersInfo();
   SOrderInfo LastState = CurrState;
   while(!IsStopped())
   {
      Sleep(10);
      CurrState = UpdateOrdersInfo();
      if(CurrState == LastState) continue;
      LastState = CurrState;
      Print("Orders changed!");
   }
   return(0);
}
//+------------------------------------------------------------------+
SOrderInfo UpdateOrdersInfo()
{
   SOrderInfo result;
   result.positionstotal     = PositionsTotal();
   result.orderstotal        = OrdersTotal();
   result.historyorderstotal = HistoryOrdersTotal();
   return(result);
}
//+------------------------------------------------------------------+

Abri várias encomendas e fechei-as manualmente.

 
Igor Makanu:

podem os serviços aceder aos ofícios? - se assim for, é possível monitorizar a cada 10ms e enviar um evento para o gráfico

Isto não é diferente da mesma ultrapassagem em sowtronic. Só que não é suficiente comparar contagens, os internos podem mudar.

 
Andrey Khatimlianskii:

Não é diferente do mesmo exagero em Owletnik. Só que não é suficiente comparar a quantidade, os internos podem mudar.

Serviços como o Alerters são muito bons. Não precisa de gráficos, eles funcionam automaticamente com o Terminal. Só tem de resolver as situações de mudança de contas.

O serviço também pode ser um conselheiro de combate. Sem a GUI, simplesmente não é muito conveniente.
 
Andrey Khatimlianskii:

Não é diferente do mesmo exagero em Owletnik. Só que não é suficiente comparar a quantidade, os internos podem mudar.

é diferente.

existem as chamadas tarefas de controlo e gestão

EA - gestão, serviço - controlo

o controlo não deve ser supérfluo - pegará em todos os recursos do sistema e obterá um sistema instável em vez de controlo

tem de definir a criticalidade dos acontecimentos, imho, encerramento e abertura das ordens - são acontecimentos críticos que precisam de controlo, ao mesmo tempo que a mudança de TP e SL poderia ser feita como antes (algumas tentativas falhadas - deixe passar, no próximo tique tentaremos novamente)

e a forma como sugere - controlando tudo é possível - pode repetir o estado das encomendas no SQLite, depois haverá um problema de sincronização da base de dados com o serviço e EA.... tudo isto é desnecessário


Penso que o esquema deveria ser mais simples - deveria ter o seguinte aspecto: obter o eventoOnTradeTransaction do terminal na EA e gerar o evento OnChartEvent do serviço para controlo adicional na EA

1...166167168169170171172173174175176177178179180...247
Novo comentário
Razão: