[¡Archivo!] Cualquier pregunta de novato, para no saturar el foro. Profesionales, no lo dejéis pasar. No podría ir a ningún sitio sin ti - 2. - página 486

[Anatoli Kazharski]

abolk:

muéstrame cómo lees la variable global_trailing_SP

Por el momento, para la posición principal, el valor de arrastre es calculado por ATR así:

void Trailing_Stop_by_ATR_SP(int Timeframe,int Period_ATR_SP,double Multiply_SP,int digits_symbol,int Magic)
{  
   double High_1     = NormalizeDouble(iHigh(Symbol(),Timeframe,1),Digits);
   double Low_1      = NormalizeDouble(iLow(Symbol(),Timeframe,1),Digits);
   double atr        = iATR(Symbol(),Timeframe,Period_ATR_SP,1);
   double new_trail  = Low_1 + NormalizeDouble(((Multiply_SP*atr)*digits_symbol)*Point,Digits);
    
   for(int count = OrdersTotal()-1; count >= 0; count--)
      {  OrderSelect(count,SELECT_BY_POS,MODE_TRADES);
      
         if (OrderType() == OP_SELL && OrderMagicNumber() == Magic)
            {  double Op_Price = NormalizeDouble(OrderOpenPrice(),Digits);
               double Stp_Loss = NormalizeDouble(OrderStopLoss(),Digits);
               
               if (new_trail < Stp_Loss && new_trail > High_1)
                  {  
                     OrderModify(OrderTicket(),Op_Price,new_trail,0,0,White);
                  }
            }
      }
}

Pero no hay ningún problema con esto, ya que la posición principal se arrastra sin errores. El problema es asignar el mismo valor a otra(s) posición(es).

[Anatoli Kazharski]

FOReignEXchange:

Así que no lo entiendo. ¿Existe la orden pendiente en el momento de la modificación de la orden principal?

Si existe, entonces la modificación de la orden principal y la modificación de la orden pendiente están en el mismo bloque. Y si la orden principal se modifica, la pendiente debería hacer lo mismo, si esa es tu idea.

Otra cosa es que nuestra idea no funcione. Eso significa un error en la condición. Trate de hacer todo de la misma manera que en la condición para la modificación de la orden principal, como he mostrado anteriormente. Me parece que el error está en la lógica. No me sorprende. Aquí todo es muy complicado. Debería ser más sencillo.

Es muy posible que deba hacerlo más sencillo. Esto es inexperiencia).

Por el momento es así, para la posición principal que se arrastra en una función separada. A continuación, si hay órdenes pendientes u otras posiciones con otros mayores, sus valores se cotejan con el stop de la posición principal. Y si son diferentes, se toma el valor del principal.

[Anatoli Kazharski]

FOReignEXchange:

No me sorprende. Es un poco complicado para ti. Deberías mantenerlo simple.

Lo he mantenido simple. El problema parece haber desaparecido hasta ahora. Combinación de arrastre para todas las posiciones. Haré la modificación de las órdenes pendientes en una función separada. Gracias)))

[Денис]

tol64:
Lo he hecho más sencillo. El problema parece haber desaparecido hasta ahora. Gracias)))

¿Qué, la pausa es modificable o algo así? :)

La letra tiene que cambiar. Cuanto más clara sea la letra, menos errores se cometerán. Intenta no meter todo en el mismo montón, con el menor número posible de variables y otras cosas innecesarias. Inicie siempre las llaves en una nueva línea para que los bloques sean claramente visibles.

[Anatoli Kazharski]

FOReignEXchange:

¿Qué, la trampa se modificó o algo así?

Sí, en la función anterior, ATR trailing, he excluido la comprobación mágica y he añadido una pausa:

if (OrderType() == OP_SELL || OrderType() == OP_SELLSTOP) 

[Anatoli Kazharski]

FOReignEXchange:

Hay que cambiar la escritura. Cuanto más clara sea la letra, menos errores se cometerán. Trate de no amontonar todo en una sola pila, con el menor número posible de variables y cosas innecesarias. Escriba siempre las llaves en una nueva línea para que los bloques sean claramente visibles.

Gracias por los consejos. Grabo lo mejor de ellos en mis neuronas)).

[Денис]

tol64:

Sí, en la función anterior, ATR trailing, excluí la comprobación mágica y añadí las pausas:

Sí. Así es, estaba a punto de decir Magik. Ya ves. No hay necesidad de variables innecesarias. Te veré más tarde.

[Andrey F. Zelinsky]

FOReignEXchange:

Sí. Es cierto, iba a decir Magik. Ya ves. No hay necesidad de variables innecesarias. Te veré más tarde.

Es una idea sabia. "No hay necesidad de variables innecesarias".
No es necesario un magik... ¿por qué comprobar el orden de un magik?
Si modifica una orden de otro EA, no habrá problema.
Deberías excluir al mago como clase en general - sus desarrolladores han perdido el tiempo - y nos han lavado el cerebro con todo tipo de magos.

p.d. Y a la bailarina, lo que estorba es mejor recortarlo.

[Anatoli Kazharski]

abolk:

sabia idea - "no hay necesidad de variables adicionales"
y "no hay necesidad de un mago" - ¿por qué comprobar la orden de un mago?
modificar una orden de otro asesor - no es gran cosa.
excluir el mago como una clase en absoluto

)))) No, creo que sería mejor dejar al mago. Debería dejar las órdenes pendientes.

Para ser más exactos, debemos dejar a los magos que se necesiten. Si utilizamos varios Asesores Expertos en diferentes gráficos, también debemos incluir los símbolos en la comprobación. Pero aún no he llegado a este punto. ))

[Денис]

Nunca uso magos en absoluto. Aunque a veces hay unos cuantos artículos a la vez. Utilizo billetes. Es mucho más fácil comprobarlo a través de OrderSelect. Y la función OrderSend se vuelve más clara. Bueno, cada uno es dueño de su propia letra. Personalmente, nunca he tenido problemas sin magos.

El billete nunca va a ninguna parte. Es conveniente con él.