[ARCHIVE]Toute question de débutant, afin de ne pas encombrer le forum. Professionnels, ne passez pas à côté. Je ne peux aller nulle part sans toi - 5. - page 352

Nouveau commentaire
 
hoz:


Ainsi, pour les ordres qui sont actifs, le prix de clôture est logiquement égal à zéro (puisqu'il n'est pas clôturé), mais pour les ordres qui ont déjà été clôturés, le prix de clôture n'est pas égal à zéro (le prix de clôture sera celui du moment où il a été supprimé). Logiquement, c'est l'heure de fermeture ?

Je comprends que les commandes ne sont pas fermées, mais supprimées, mais comment l'implémenter autrement ?


MODE_TRADES (par défaut) - l'ordre est sélectionné parmi les ordres ouverts et en attente,
MODE_HISTORY - l'ordre est sélectionné parmi les ordres fermés et supprimés.
 

Il a raison, mais les crochets sont tous faux.

2hoz- mon conseil pour vous, jetez cet algorithme. Pourquoi avez-vous besoin de faire glisser un tas d'ordres en attente sur le graphique ?

Une grille fonctionne très bien avec seulement quelques pendentifs :

1) vous placez initialement une paire d'ordres stop.

2) quand l'un d'eux se déclenche, juste après (à la distance requise) vous en exposez un autre. L'opposé est tiré vers le prix à la distance requise.

C'est tout. Ainsi, vous n'avez toujours que 2 ordres en attente et vous n'avez pas de problèmes avec les recalculs.

 
Les gars, aidez-moi avec quelques conseils.https://www.mql5.com/ru/forum/142582/page351
 
FAQ:
J'ai signalé l'erreur avec les parenthèses.


Oui, j'ai déjà retravaillé l'ensemble, j'avais aussi un bug avec la nullité des variables de prix extrêmes au début de la fonction (c'est-à-dire qu'avant c'était 2 et maintenant c'est 4). Tout fonctionne, merci.

FAQ:

Il a fait tout ce qu'il fallait, mais il s'est trompé dans les crochets.

2hoz- mon conseil pour vous, jetez cet algorithme. Pourquoi avez-vous besoin de faire glisser un tas d'ordres en attente sur le graphique ?

Une grille fonctionne très bien avec seulement quelques pendentifs :

1) vous placez initialement une paire d'ordres stop.

2) quand l'un d'eux se déclenche, juste après (à la distance requise) vous en exposez un autre. L'opposé est tiré vers le prix à la distance requise.

C'est tout. Ainsi, vous n'avez toujours que deux ordres en attente et vous n'avez aucun problème avec les recalculs.


Nous pouvons le faire de cette façon, mais comme je le vois, si l'écart entre les ordres en attente est faible, les ordres en attente peuvent ne pas avoir assez de temps pour être fixés. Vous n'êtes pas d'accord avec moi ? Après tout, si un ordre en attente est défini, il sera déclenché. Et, si le pas est petit, il faut le fixer, ce qui, là encore, entraîne la possibilité de dérapages car l'ordre n'est pas toujours proche de l'endroit où il est nécessaire.

De plus, je ne place pas toujours la grille entière. En fait, un seul ordre extérieur est supprimé et deux ordres sont placés (l'un est court et l'autre est long). Ainsi, il s'avère qu'avec les mêmes conditions d'égalité, ce sera bon, car même avec un coup fort, vous pouvez saisir l'ensemble du coup.

 

Veuillez aider à résoudre le problème de la limite de la valeur de décalage dans iHigh(Symbol(),timeframe,shift), qui est limitée au nombre 1000.

iTime(Symbol(),timeframe,1001) donne 1970.01.01 00:00
 
hoz:


J'ai déjà tout changé, il y avait un problème de nullité des variables de prix extrêmes au début de la fonction (c'est-à-dire qu'avant c'était 2 et maintenant c'est 4). Tout a marché, merci.


Nous pouvons procéder de cette manière, mais si je comprends bien, si le pas entre les pauses est faible, les pauses risquent de ne pas avoir suffisamment de temps pour être fixées. Vous n'êtes pas d'accord avec moi ? Après tout, si un ordre en attente est défini, il sera déclenché. Et, si le pas est petit, il faut le fixer, ce qui, là encore, entraîne la possibilité de dérapages car l'ordre n'est pas toujours proche de l'endroit où il est nécessaire.

De plus, je ne place pas toujours la grille entière. En fait, un seul ordre extrême est supprimé et 2 ordres sont fixés (l'un est court et l'autre est long). Il en ressort donc qu'à conditions égales, ce sera bon, car même avec un coup fort, on peut saisir tout le coup.


1) Y croyez-vous ? Vous le croyez ? Oui, lors d'un bon mouvement sur le réel, le courtier déplacera la moitié des ordres par prix et les ouvrira tous ensemble et même au-delà du takeprofit, et les fermera immédiatement au stop et le reste peut ne pas s'ouvrir du tout. Et il aura raison.

2) Je n'ai pas encore vu un si bon mouvement que l'EA n'ait pas réussi à placer des ordres en attente.

Mais j'ai vu un grand nombre de plaintes contre le courtier dans cette situation. Je n'ai jamais vu un aussi bon coup sans un coup en attente.

 
Fox_RM:
Les gars, aidez-moi avec quelques conseils.https://www.mql5.com/ru/forum/142582/page351


Je pense qu'il y a un problème ici.

 for (i=0; i<=colbr; i++)
{VLUP += MathAbs(iVolume(NULL,0, shift+i));}
}


    
   Comment("Vol_",VLUP,prlw_e,prhgh_e); 
  for(i=0; i<limit; i++)
   {     
SetText("Awesome_super_volumes"+Close[i], DoubleToStr(VLUP,0), tmlw, AO_dn, Black);     
 }
        
Lorsque vous ouvrez le graphique limite, vous êtes égal au nombre de barres, vous comptez d'abord le montant du VLUP et ensuite vous le mettez dans tous les points par shambles. Il comptera probablement correctement par la suite.
 
Serg16:

Veuillez m'aider à résoudre le problème de la limite de décalage dans iHigh(Symbol(),timeframe,shift), qui est limitée au nombre 1000.

iTime(Symbol(),timeframe,1001) donne 1970.01.01 00:00

Ouvrez Service->Paramètres->Graphes. Voyez combien de barres vous avez prévu pour le graphique. Je l'ai fait fonctionner avec 2000 et 3000.
 
Pour la deuxième fois en un mois, toutes les factures du navigateur disparaissent dans le terminal, je dois les restaurer à partir de la mylebox du terminal, et la dernière fois la mylebox était vide ...., qu'est-ce que c'est que cette absurdité, quelqu'un l'a t-il vécu ?
 
Roger:

Ouvrez Service->Paramètres->Chartes. Vérifiez le nombre de barres que vous avez prévu pour le graphique. Je l'ai réglé sur 2000 et 3000.

Bars en fenêtre 2147483647 et Bars en histoire 2147483647

J'ai modifié ce chiffre pour afficher correctement les minutes importées pendant 12 ans. Je commence à tester l'année 2010, par exemple, mais pas plus de 1000 pièces par période. J'utilise 451 bild.


Veuillez m'aider à résoudre le problème de la limitation de la valeur de décalage dans iHigh(Symbol(),timeframe,shift) qui est limitée au nombre 1000.

iTime(Symbol(),timeframe,1001 ) donne 1970.01.01 00:00


Par exemple, la commande Print ("s=",s," ",Time[s]) ;

10:55:09 2010.03.01 00:00 repit_003 EURUSD,M30 : s=999 1264730400
10:55:09 2010.03.01 00:00 repit_003 EURUSD,M30 : s=1000 1264728600
10:55:09 2010.03.01 00:00 repit_003 EURUSD,M30 : s=1001 0
10:55:09 2010.03.01 00:00 repit_003 EURUSD,M30 : s=1002 0
10:55:09 2010.03.01 00:00 repit_003 EURUSD,M30 : s=1003 0
10:55:09 2010.03.01 00:00 repit_003 EURUSD,M30 : s=1004 0

1...345346347348349350351352353354355356357358359...432
Nouveau commentaire