![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Bonjour, Anton !
Suivant vos conseils (LoadServerData() appelle SeriesInfoInteger( a_symbol, PERIOD_M1, SERIES_SERVER_FIRSTDATE),
c'est-à-dire qu'on lit "première date dans l'historique par symbole sur le serveur sans tenir compte de la période".
Cette requête elle-même n'est pas considérée comme une requête d'historique, c'est-à-dire qu'elle ne provoque pas la construction d'un cache,
n'empêche pas le déchargement des données du symbole. Il est logique de demander soit SERIES_FIRSTDATE, soit le nombre de barres de la série chronologique.),
J'ai ajouté une nouvelle fonction à l'indicateur pour empêcher le déchargement des données des symboles :
La fonction OnBookEvent() est déclenchée assez souvent sur les caractères BR-8.15 et BR-9.15,
mais le résultat est le même :
Alors quel est le problème ?
Pourquoi est-il impossible d'obtenir des Bars ?
La fonction OnBookEvent() se déclenche assez souvent sur les caractères BR-8.15 et BR-9.15,
mais le résultat est le même :
Alors quel est le problème ?
Pourquoi est-il impossible d'obtenir des Bars ?
La fréquence des "assez souvent" n'inspire pas confiance. Il est préférable d'ajouter la sortie du journal de la fonction GetBars() pour le débogage.
Si vous voulez le comprendre, ouvrez une demande dans Servicedesk. Joignez un exemple de code complet, nous allons essayer de reproduire le problème.
La fréquence des "assez souvent" n'inspire pas confiance. Il est préférable d'ajouter la sortie du journal de GetBars() pour le débogage.
Si vous voulez le découvrir, ouvrez une demande dans le servicedesk. Joignez un exemple de code complet, essayons de reproduire le problème.
Ok. Demande :Erreurs,MetaTrader 5 Client,Ouvert,Démarré : 2015.07.24 18:28,#1267768
P/S "Assez souvent", c'est 10 à 100 déclenchements OnBookEvent() sur deux instruments très liquides par MINUTE.
Hourra !
J'ai reproduit le problème. En effet, les données des symboles étaient parfois déchargées de la mémoire même avec des requêtes périodiques. L'erreur sera corrigée.
Merci !
Michael, avez-vous réussi à surmonter ce problème d'obtention de séries à partir d'autres symboles ? J'en ai assez de me battre avec mon indicateur, il perd constamment la synchronisation avec les autres symboles.
En ce moment, le serveur de démonstration donne la Build 1159 du 22 juin 2015. Et les indicateurs multidevises y fonctionnent aussi très mal. Vous devez changer de période plusieurs fois ou redémarrer l'indicateur pour qu'il s'affiche correctement. Et au bout d'un moment, il ne récupère plus les données de la série. J'écris toujours dans le journal.
Данные символа "Si-12.15" не синхронизированы с торговым сервером.
Aux développeurs:
Est-il impossible de faire une fonction, non pas pour vérifier si les données sont synchronisées ou non, mais directement pour synchroniser et non pas pour décharger ces données de la mémoire ?
L'économie de ressources est bonne, en termes d'optimisation des algorithmes. Mais pourquoi devrais-je être aussi fanatique pour décharger les données de la mémoire ?
Je préfère acheter un ou deux gigaoctets de mémoire supplémentaires dans mon PC plutôt que de m'embêter avec cette pénible synchronisation de séries.
Créez une fonction qui est appelée une fois à OnInit() pour charger les données du symbole requis et qui ne sera pas déchargée avant l'exécution de l'indicateur.
Le terminal doit préparer les données et contrôler leur pertinence, au lieu que l'utilisateur pense au premier rendez-vous, au nombre de bars que j'ai et au serveur, etc.
Michael, avez-vous réussi à surmonter ce problème d'obtention de séries à partir d'autres symboles ? J'en ai assez de me battre avec mon indicateur, il perd constamment la synchronisation avec les autres symboles.
Actuellement, le serveur de démonstration émet la build 1159 du 22 juin 2015. Et les indicateurs multidevises y fonctionnent également très mal. Vous devez changer de période plusieurs fois ou redémarrer l'indicateur pour qu'il s'affiche correctement. Et au bout d'un moment, il ne récupère plus les données de la série. J'écris toujours dans le journal.
Aux développeurs:
Est-il impossible de faire une fonction, non pas pour vérifier si les données sont synchronisées ou non, mais directement pour synchroniser et non pas pour décharger ces données de la mémoire ?
L'économie de ressources est bonne, en termes d'optimisation des algorithmes. Mais pourquoi devrais-je être aussi fanatique pour décharger les données de la mémoire ?
Je préfère acheter un ou deux gigaoctets de mémoire supplémentaires dans mon PC plutôt que de m'embêter avec cette pénible synchronisation de séries.
Créez une fonction qui est appelée une fois dans OnInit() pour charger les données pour le symbole requis et qui ne sera plus déchargée jusqu'à ce que l'indicateur fonctionne.
Le terminal doit préparer les données et surveiller leurs mises à jour, au lieu que l'utilisateur pense au premier rendez-vous, au nombre de bars que j'ai et au serveur, etc.
Bonjour !
Les développeurs ont répondu qu'ils allaient corriger ce problème dans la nouvelle version.
La date de sa sortie n'est pas encore connue.
FORTS. J'ai rencontré un problème, les fonctions OrderCheck() et OrderCalcMargin() déterminent parfois ( !) incorrectement le GO requis pour une transaction et renvoient donc FALSE.
Avec le GO requis pour RTS-12.15(SYMBOL_MARGIN_INITIAL) de 12.500 , la fonction nécessite pas moins de 143.105 roubles !
En même temps, tout s'ouvre parfaitement manuellement.
Comment puis-je appeler :
Essayez de cette façon :
Voici mon résultat :