Servicedesk. Plaintes, suggestions.
Il a été dit "amenons cette discussion sur le forum".
De quoi allez-vous discuter sur le forum, de ma grossièreté ou du problème du nettoyage de la mémoire ?
On vous a dit "amenons cette discussion sur le forum".
De quoi allez-vous discuter sur le forum, de mon impolitesse ou du problème de nettoyage de la mémoire ?
J'ai donc lancé la discussion sur le forum. Rendons-le compatible.
Au sujet de l'impolitesse. Ce n'est pas toujours agréable de parler à Searcydesk. Arguments ci-dessus.
A propos de la fonction. J'ai donné des preuves que la fonction ne fonctionne pas correctement. Vous m'avez offert des "béquilles". Si vous ne pouvez travailler correctement que sans béquilles, ajoutez une description de ces béquilles à la documentation afin qu'aucune question ne se pose à l'avenir.
Je demande aux programmeurs de partager leurs opinions. Êtes-vous satisfait du comportement de la fonction SeriesInfoInteger()? Êtes-vous satisfait de la documentation linguistique ?
J'ai soulevé le problème des données dans les indicateurs il y a longtemps !
https://www.mql5.com/ru/forum/42180
On m'a assuré que le problème avait été résolu.
Ils ont même écrit à ce sujet dans le résumé de la version 1200.
17 :Terminal : Correction d'une erreur qui entraînait le déchargement des données historiques comme étant inutilisées, malgré des accès réguliers aux données par les programmes MQL5.
Leproblème n'a donc pas été résolu?
- www.mql5.com
J'ai soulevé le problème des données dans les indicateurs il y a longtemps !
https://www.mql5.com/ru/forum/42180
On m'a assuré que le problème avait été résolu.
Ils ont même écrit à ce sujet dans le résumé du communiqué de presse 1200.
17 :Terminal : Correction d'une erreur qui entraînait le déchargement des données historiques comme étant inutilisées, malgré des accès réguliers aux données par les programmes MQL5.
Donc le problème n'a pas été résolu?
Je voulais dire MT4 dans ce cas. Mais pour MT5, la question est également pertinente.
Dans ce cas, je faisais référence à MT4. Mais pour MT5, la question est également pertinente.
Je n'ai pas encore mis à jour vers 1200, je ne peux pas vérifier si c'est corrigé ou non.
Mais il y avait un tel bug dans MT5
Je n'ai pas encore mis à jour vers 1200, je ne peux pas vérifier si c'est déjà corrigé.
Mais il y avait un tel bug dans MT5
Maintenant, il télécharge 1204. Voyons voir.
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
Bon après-midi. Aujourd'hui, j'ai de nouveau été confronté au fait que le Service Desk n'est pas toujours disposé non seulement à entendre parler du problème, mais ne veut même pas l'écouter. Commençons.
Il y a quelques jours, j'ai écrit une autre demande à Servicedesk. L'essentiel de la demande est le suivant (pour MT4) :
Индикатор находится на ТФ, старше М1. Пытаюсь получить данные через функцию SeriesInfoInteger() с ТФ М1. Функция возвращает нули для свойств SERIES_BARS_COUNT, SERIES_FIRSTDATE, SERIES_SERVER_FIRSTDATE после того, как на М1 образовался новый бар. До того, как образовался новый бар - данные возвращаются корректные. После - нули.
Le deuxième problème, d'un type similaire. L'indicateur est sur TF MN1. J'essaie de recevoir des données via la fonction SeriesInfoInteger() du TF M5. Pendant un certain temps, la fonction renvoie des valeurs correctes, puis elle cesse de le faire et commence à renvoyer des zéros, bien qu'AUCUN NOUVEAU BAR N'A ÉTÉ OUVERT SUR LE M5 !
Dans les deux cas, après être revenu au TF à partir duquel j'essaie d'obtenir des données et être repassé à un TF supérieur, les données sont correctes pendant un moment, mais ensuite - des zéros.
L'indicateur se trouve dans l'application.
J'ai besoin des propriétés ci-dessus de la fonction SeriesInfoInteger() pour vérifier/charger l'historique disponible pour le TF autre que celui de l'indicateur.
Aucun programmeur n'appréciera l'ambiguïté du type suivant : au début, il y a des données, puis il n'y a pas de données et elles ne peuvent pas être obtenues. De plus, l'utilisateur ou les utilisateurs, pour qui le programme est écrit, ne l'apprécieront pas. Vous pouvez voir dans le message que j'ai fourni le programme pour tester cette erreur. De plus, un journal a même été fourni :
Les données sont simplement abandonnées et ne peuvent être récupérées qu'en changeant le TF pour celui pour lequel la demande de données est faite.
Et voici la réponse que me donne le SR.
Statut :OuvertFermé
Vous pouvez voir dans ce message que le Service Desk (ou certains de ses employés) ne se soucie pas du tout de ce que les utilisateurs écrivent sur les erreurs. On me demande d'accéder aux données plus fréquemment qu'une fois toutes les 10 secondes !? Le journal montre que les données sont demandées beaucoup plus souvent, à chaque tic. Je suis sûr que ce journal n'a même pas été lu. Mais on m'a suggéré d'y accéder "plus souvent" ou d'accéder aux données à partir de l'EA. Génie. Oh, et la demande a été immédiatement fermée, comme si j'avais reçu de l'aide.
On avance. Voici ma réponse :
Avez-vous identifié l'erreur ?
Et la réponse du Service Desk :
Ouvrez le graphique souhaité, ses données seront toujours en mémoire jusqu'à ce que vous le fermiez.
Depuis la version 900, nous avons implémenté une libération agressive de la mémoire. S'il y a un problème de mémoire, tout ce qui peut être libéré est libéré.
J'ai besoin de ces propriétés afin de sélectionner la plus petite TF appropriée qui dispose de suffisamment de données. Moi, par contre, on me propose d'ouvrir chaque graphique. Et peu importe le nombre d'instruments que j'analyse en même temps, ouvrez tous les graphiques possibles et vous serez heureux.
A propos de la libération agressive et des problèmes de mémoire. Le terminal n'a pas de problèmes de mémoire. Il n'y a pas d'erreurs dans les journaux du terminal. On peut en déduire que je viens d'être informé d'une situation où la mémoire pourrait être libérée. Mais ce n'est évidemment pas mon cas. Un autre fait est que le Service Desk ne veut pas examiner le problème et veut simplement s'en débarrasser.
Suivant.
Ne pensez-vous pas qu'il est préférable d'affiner le communiqué sur la mémoire agressive plutôt que d'étoffer les graphiques ? Et de quels problèmes de mémoire parlez-vous ? Et oui, libérez, mais faites en sorte qu'il soit possible de les récupérer plus loin sans béquilles !
Avez-vous essayé d'exécuter l'indicateur à partir de l'application ? Comprenez-vous que les données proviennent de la TF de quelqu'un d'autre, viennent, viennent, et bam - arrêtez de le faire !? Est-ce un comportement normal ?
Voici un extrait de la documentation :
Pour les conseillers experts et les indicateurs personnalisés, il est préférable d'utiliser le modèle de traitement basé sur les événements. Si les événements OnTick() ou OnCalculate() n'obtiennent pas toutes les données nécessaires, vous devez quitter le gestionnaire d'événements, en espérant que les données seront disponibles la prochaine fois que le gestionnaire sera appelé.
L'indicateur que j'ai cité utilise exactement ce modèle. Si aucune donnée n'est reçue, les données sont censées arriver au prochain tick. Mais les données ne viennent plus ! Pas du tout ! C'est une contradiction de documentation !
Dans mql5 tout fonctionne comme il se doit, pourquoi ne peut-on pas l'organiser de la même manière dans mql4 ?
Et la réponse :
Non, ça ne l'est pas.
En ce qui concerne la documentation, voici une conclusion simple : si vous avez constamment besoin de données d'une certaine période de symbole, assurez-vous de la présence constante de ces données dans OnInit. Par exemple, avec une simple requête iTime(symbole_nécessaire,période_nécessaire). Et gardez cet iTime sur chaque tic.
Vous chargez vous-même votre terminal de la mémoire. Réduisez donc le nombre de barres du graphique à la limite nécessaire. Pour sauvegarder des données critiques, ouvrez le graphique avec le symbole-période adéquat.
Si vous n'êtes pas satisfait de l'état actuel des choses, discutons-en sur le forum. Il est inutile d'en discuter ici.
Le MT5 a un modèle complètement différent d'utilisation des données historiques.
Dans l'ordre :
Non. Ça ne semble pas l'être.
Juste rustre. Pas d'explication, pas de commentaire.
En ce qui concerne la documentation, la conclusion est simple : si vous avez besoin de données sur la période du symbole en permanence, assurez-vous que ces données sont toujours présentes dans OnInit. Par exemple, avec une simple requête iTime(symbole_nécessaire,période_nécessaire). Et gardez iTime sur chaque tique.
Première béquille de bon sens. Une déduction simple ! ? Où est cette conclusion ? Pensez-vous vraiment que tous ceux qui écrivent en mql ont tiré cette conclusion pour eux-mêmes ? Ne spéculez pas pour les gens. Des conclusions sont tirées de ce qui est écrit. À titre de comparaison. Dans la documentation de mql5, dans la section "Organisation de l'accès aux données", il y a un exemple de la façon dont l'accès aux données doit être organisé. Tout fonctionne parfaitement. Ici, vous devez deviner que si la fonction SeriesInfoInteger() renvoie 0, vous devez appeler la fonction iTime() pour le symbole/période nécessaire. Pourquoi n'y a-t-il pas d'écrits à ce sujet ? Pourquoi ne pouvons-nous pas simplement améliorer la fonction SeriesInfoInteger() sans ces béquilles ? Ou au moins le clarifier dans la documentation ? Chers développeurs, si vous voulez avoir moins de questions, écrivez dans la documentation une fois en détail comment et quoi. Les gens savent lire !
Vous chargez vous-même votre terminal de la mémoire.
Je me demande ce que tu voulais me dire ! Le terminal peut consommer de la mémoire, mais surcharger le terminal de mémoire est quelque chose de nouveau pour moi.
Réduisez donc le nombre de barres du graphique à la limite nécessaire. Pour sauvegarder des données critiques, ouvrez le graphique avec le symbole-période adéquat.
Combien de barres pensez-vous que je testais l'indicateur dans l'application ? Vous ne semblez pas vous en soucier, car vous n'avez même pas demandé. C'est un nombre de 5000. C'est le minimum possible. Et à nouveau la suggestion d'ouvrir le tableau. Je l'ai, merci. Ajoutez-le à la documentation (si nécessaire).
Et final.
Si vous êtes mécontent de l'état actuel des choses, portons cette discussion sur le forum. Il est inutile d'en discuter ici.
MT5 a un modèle complètement différent d'utilisation des données historiques.
Oui, je ne suis pas satisfait de l'état actuel des choses. Les utilisateurs trouvent des erreurs (je considère toujours le comportement de la fonction SeriesInfoInteger() comme une erreur) dans votre programme. Ils le font gratuitement. Et ce n'est pas que vous ne voulez pas les corriger, vous ne voulez même pas les écouter et examiner les données fournies par les utilisateurs. Et ce n'est pas la première fois, lorsque les faits sont acceptés à bras-le-corps, que vous ne vous souciez pas des erreurs. J'espère que les développeurs écouteront et qu'il y aura des changements positifs à l'avenir. Votre attitude actuelle va dépopulariser l'attitude envers vous et votre produit.
Merci à tous d'avoir lu.
Si quelqu'un souhaite tester cette fonctionnalité, l'indicateur se trouve en annexe.