Erreurs, bugs, questions - page 849

 
Heroix:

Il s'agit de deux terminaux sur un seul ordinateur. À toutes les suggestions de mise à jour faites par le terminal, je réponds "oui".

Le fichier a été transféré à Flash depuis un autre ordinateur sous le format .mql5, ouvert et compilé par différents éditeurs de deux terminaux.

Bref, si j'ai bien compris, je dois mettre à niveau MT...

Si vous effectuez une mise à niveau manuelle, vous devez également transférer le dossier /MQL5, car il contient un grand nombre de bibliothèques standard que vous utilisez.

Comme vous n'avez transféré que les exécutables et votre code source sous forme de fichier mq5, vous avez fait une erreur.

 
OrderLots() et iClose comme possible dans MQL 5 ???
 

On est passé à Bild 695. Une erreur est apparue lors de la compilation de Object.mqh.


 
denkir:

On est passé à Bild 695. Une erreur est apparue lors de la compilation de Object.mqh.

La mise à jour s'est-elle faite automatiquement ou avez-vous simplement déplacé les fichiers ?

Si vous l'avez fait automatiquement, lors du stockage des fichiers dans UserData, copiez le répertoire /MQL5 de la racine du programme vers le répertoire des données (vous pouvez l'ouvrir à partir du menu Fichier).

 
Aux développeurs

Qu'est-il arrivé au calendrier économique, existe-t-il ?

Question supplémentaire : sur quelles données s'appuie-t-il et comment peut-il être " branché " sur le CC ?

 
papaklass: Les données ne coïncident pas, mais elles devraient, car les deuxième et troisième cas sont des parties distinctes de la première condition. Je n'arrive pas à comprendre quel est le problème.

C'est la condition

if( mn < STP || mn >= STP )

- il est formulé de cette façon pour quelle raison ? En l'état, il fonctionnera pour n'importe quel mn et STP. Pourquoi devons-nous l'introduire ? Et les deux options suivantes - il y a une coupure spécifique de certaines situations.

Mais tout semble logique : un + deux == trois (sans entrer dans le détail des calculs un, deux et trois) dans les trois variantes.

 
papaklass:

C'est de ça que je parle. Je veux diviser l'espace commun (cas 1) en deux groupes (cas 2 et 3). Logiquement, l'expression un + deux == trois devrait être vraie, mais elle ne l'est pas. Dans la première condition on=148, et dans la seconde 172. Pas de correspondance non plus pour deux et pour trois. Je ne sais pas quel est le problème.

Peut-être le problème réside-t-il dans une condition commune ? Ce code dépend-il de quelque chose d'autre ?

Juste un exemple trivial :

condition (a) : ouvrir si la barre sur H1 monte. TP=SL=100

condition (b) : Ouvrir si la barre sur H1 diminue. TP=SL=100

Condition supplémentaire : nous ne vérifions pas les conditions pour la deuxième fois, si nous avons déjà une position.

Ensuite, si nous activons (a) plus (b), nous ouvrirons chaque fois que le TP/SL est déclenché.

si nous incluons (a), nous ouvrirons dans toutes les premières fois plus ( !!!!) quelques fois de plus où nous n'avons pas ouvert parce que nous avons ouvert avant avec la condition (b).

et d'inclure uniquement la condition b), de manière similaire

 
papaklass: Logiquement, l'expression un + deux == trois devrait être correcte, mais elle ne fonctionne pas pour moi.

Regardez de plus près : c'est exactement la comparaison (un + deux == trois) qui est effectuée, pour chacune des options.

papaklass: Dans la première condition on=148, et dans la seconde 172.

Il s'agit d'une autre question, à savoir pourquoi la valeur d'une personne de la première variante n'est pas égale à la valeur d'une personne de la deuxième et de la troisième variante.

Vous introduisez une condition restrictive dans les deuxième et troisième variantes par rapport à la première variante. Examinez pourquoi, par exemple, dans la deuxième variante, la valeur de un augmente par rapport à la première variante. La partie du code citée jusqu'à présent n'est pas claire.

 
papaklass:

Au poste précédent.

Dans le troisième cas : un=0, deux=124, trois=124.

Les données ne correspondent pas, mais elles devraient, car les deuxième et troisième cas sont des parties distinctes de la première condition. Je ne comprends pas quel est le problème.

PS : entrée int STP=200 ;

Résultat correct avec le changement de jeu de données, puisque l'espace mn<STP que vous avez exclu.

if( /*mn < STP || */ mn >= STP ){
 
papaklass: Dans mes exemples, je fais simplement un échantillonnage :

1. Je choisis à la fois l'espace2 (un) et l'espace3 (deux) ; 230 = 148 + 82, c'est-à-dire espace2 (un) = 148 et espace3 (deux)=82.

2. ... Devait rester 148, et est devenu 172.

3. ... Devrait rester 82, et devient 124.

C'est ce dont je parle : la question que vous vous posez est de savoirpourquoi la valeur d'un élément de la première option n'est pas égale à la valeur d'un élément des deuxième et troisième options.

Les valeurs des espaces 2 et 3 doivent être constantes, car les conditions d'obtention de ces espaces sont les mêmes dans les trois exemples que j'ai donnés dans les posts précédents.

Pour trouver une erreur dans cette hypothèse logique, je suggère de faire très simplement : imprimer chaque cas d'augmentation des "espacesX" dans les trois variantes, comparer les résultats et analyser pour quelle raison les "valeurs des espaces2 et des espaces3" ne sont pas les mêmes.

Addendum. ilunga a déjà laissé entendre que certaines transactions pourraient être perdues lors du passage d'une variante à une autre. Vous avez une fonction/méthode tueuse OpenPosition() intégrée dans le corps de l'opérateur if(). Et il fonctionne à des moments différents selon la condition vérifiée par l'opérateur if().

Raison: