Erreurs, bugs, questions - page 1565
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Je l'ai lu et très attentivement. Le fait est que si Sleep est utilisé dans OnTimer, il est impossible de déterminer quand vous quittez l'intervalle de test. IsStopped (je l'ai mis dans le code en une fois à cause de la lecture de la documentation) ne fonctionne pas au moment de la sortie. A qui la faute ?
Pourquoi faut-il déterminer le moment où l'on sort de l'intervalle de test ? Le testeur le détectera pour vous et arrêtera le test. Avez-vous lu exactement la citation que je vous ai donnée ?
Pourquoi déterminer le moment où l'intervalle de test est dépassé ? Le testeur le déterminera pour vous et arrêtera le test. Avez-vous bien lu ma citation ?
Veuillez regarder mon code source ci-dessus et indiquer où il contient une erreur logique. Je ne sors pas de l'intervalle, nulle part.
IsStopped() ne devient pas vrai lors de la rupture de l'intervalle dans OnTimer. C'est pourquoi c'est une déception.
Vous êtes sérieux ?
Un tick est joué, et vous pouvez immédiatement le prendre encore chaud avec la requête SymbolInfoTick. J'ai tout de suite écrit sur cette possibilité. Si vous le souhaitez, vous pouvez utiliser Sleep(1) au lieu de Sleep(10).
Sérieusement ! Sleep(1) ne sera pas utile car il y a plusieurs ticks par 1 ms sur le même FORTS.
De plus, comment le Sleep(1) fonctionnera-t-il le week-end ? Il y aura des millions de chèques sans provision. C'est du gaspillage.
MQL4. TimeToString() et TimeToString(). Dans les paramètres du 2ème argument, il est écrit "TIME_MINUTES obtient le résultat sous la forme " hh:mm "" et "TIME_SECONDS obtient le résultat sous la forme " hh:mm:ss "". Cela devrait être corrigé en " hh:mi " et " hh:mi:ss ".
mi - ce format n'existe pas. Il y a mm - qui signifie minutes. Et mmm signifie mois.
_MQL4_
intArrayMinimum(const void&array[],// tableau à rechercher
intcount=WHOLE_ARRAY// nombre de testés
intstart=0,// index à partir duquel la recherche est lancée
) ;
_MQL5_
intArrayMinimum(const void&array[],// tableau à rechercher
intstart=0,//l'index à partir duquel la recherche est lancée
intcount=WHOLE_ARRAY// nombre de vérifiés
) ;
C'est censé rendre la vie douce ? Brillant.
Dans ce cas, le format "yyyyy.mm.dd hh:mi" devrait être corrigé en "yyyyy.mmm.dd hh:mm".
mm - deux chiffres du mois,
dd - signes de deux jours,
hh - deux chiffres des heures,
mm est un nombre à deux chiffres de minutes.
Mais mi est un signe pour les minutes et un signe pour quoi ? Je croyais que c'était un indice de cycle.
Alors n'inventez pas de normes pour raccourcir les formats de temps, s'il vous plaît. Pas besoin de confusion...
yyyy - quatre chiffres de l'année,
mm - deux chiffres du mois,
dd - signes de deux jours,
hh - deux chiffres des heures,
mm - deux chiffres des minutes.
Mais mi est un signe pour les minutes et un signe pour quoi ? Je croyais que c'était un indice de cycle.
Alors n'inventez pas de normes pour raccourcir les formats de temps, s'il vous plaît. Pas besoin de confusion...
Rappelons-nous où j'ai commencé ce fil. Le but n'est pas de changer le format, mais la documentation MQL4 TimeToString() et TimeToStr() devrait être corrigée (image ci-dessous), rien de plus.