Erreurs, bugs, questions - page 1500
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
Comment pouvez-vous ne pas comprendre que vous demandez aux développeurs de supprimer la possibilité de travailler avec le calendrier actuel ? Si vous ne voulez pas contrôler correctement le processus de création, de travail et de suppression des objets, surchargez vous-même la méthode Open, comme le suggèrent les développeurs.
En fait, lorsque vous créez un objet de classe, tous ses champs sont initialisés avec des zéros, ce n'est pas du pur C++, où vous êtes obligé de tout remettre à zéro après la création.
Et vous créez un objet de classe, vous travaillez avec lui et vous lancez simplement l'objet à supprimer, sans détacher le graphique de l'objet de classe. Et les développeurs vont changer la méthode Open et se demander pourquoi la méthode Attach surchargée a été créée en premier lieu ?
Développeurs, veuillez envisager de briser votre propre idéologie de travail avec la bibliothèque standard avant d'effectuer ces changements.
Comment pouvez-vous ne pas comprendre que vous demandez aux développeurs de supprimer la possibilité de travailler avec le calendrier actuel ? Si vous ne voulez pas contrôler correctement le processus de création, de travail et de suppression des objets, surchargez vous-même la méthode Open, comme le suggèrent les développeurs.
En fait, lorsque vous créez un objet de classe, tous ses champs sont initialisés avec des zéros, ce n'est pas du pur C++, où l'on est obligé de tout remettre à zéro après la création.
Et vous créez un objet de classe, vous travaillez avec lui et vous lancez simplement l'objet à supprimer, sans détacher le graphique de l'objet de classe. Et les développeurs changeront la méthode Open et se demanderont pourquoi la méthode Attach surchargée a été créée en premier lieu.
Développeurs, veuillez envisager de briser votre propre idéologie de travail avec la bibliothèque standard avant d'effectuer ces changements.
Communiquons par des exemples. Vos accusations non fondées deviennent ennuyeuses. Et qu'est-ce qui vous fait penser que votre approche, à mon avis fondamentalement fausse, est correcte ?
Et vous, après avoir créé un objet de classe, travaillé avec lui, vous jetez simplement l'objet, sans détacher le graphique de l'objet de la classe. Les développeurs vont maintenant modifier la méthode Open, ce qui amène à se demander pourquoi la méthode Attach surchargée a été créée en premier lieu.
Comment changer de GMT ? "C'est un monument !" (c) GMT est le temps moyen de Greenwich
Hahaha...
Vous êtes si spirituel.
Communiquons par des exemples. Vos accusations non fondées commencent à nous ennuyer. Et qu'est-ce qui vous fait penser que votre approche, à mon avis fondamentalement fausse, est correcte ?
La méthode Detach() est un sujet de discussion distinct. Ce dont nous discutons maintenant, c'est que Open() peut imposer le travail avec le graphique actuel implicitement ! Pour cela, il existe la méthode Attach(). Il n'est pas clair qui et quoi sera tué lors de l'ajustement de la méthode Open()...Pensez ce que vous voulez, mais ces lignes de code dans la mise à jour proposée de l'Open :
changera le champm_chart_id contenant l'ID du graphique en -1, si le graphique est actuel c'est-à-dire ( 0 ), quel genre d'accusations infondées peuvent-elles être, et personne ne vous accuse, vous êtes confus. Si vous ne voulez pas écrire selon l'idéologie de la bibliothèque standard, surchargez les méthodes qui, selon vous, ne fonctionnent pas comme vous le souhaitez. Je comprends si la classe est intégrée dans un mécanisme commun, comme par exemple la famille de classes des panneaux de contrôle, où certaines méthodes ne peuvent pas être surchargées à cause des champs qu'elles contiennent dans la section privée de la classe. Mais ici la classe est simple, vous pouvez changer son comportement vous-même. Mais si les développeurs modifient la méthode Open comme décrit ci-dessus, alors la méthode Attach() ne sera pas claire, car il s'agit du graphique actuel ( 0 ). En d'autres termes, le prochain appel à Open aura pour résultatm_chart_id == -1.
En fait, ce n'est pas un problème pour moi, j'ajoute simplement une ligne à OnInit qui récupère l'ID du graphique actuel et lie le graphique à l'objet de classe en utilisant la méthode Attach(long chart), mais certains des développeurs qui ne lisent pas cette branche, peuvent avoir des situations étranges et "inattendues".
Existe-t-il un moyen de copier les variables du fichier ex4 ?
sauvegarder le fichier défini - je fais toujours cela
:))
Tu ne peux pas.
Dans les fichiers mq4, vous pouvez.
(indicateur)
:))
Tu ne peux pas.
Dans les fichiers mq4, vous pouvez.
(indicateur)
Un modèle ? Il n'y a pas de type de données.
Pensez ce que vous voulez, mais ces lignes de code dans la mise à jour proposée de l'Open :
changera le champm_chart_id contenant l'ID du graphique en -1, si le graphique est actuel, c'est-à-dire ( 0 ). Quel genre d'accusations infondées sont là, et personne ne vous accuse, vous êtes confus. Si vous ne voulez pas écrire selon l'idéologie de la bibliothèque standard, surchargez les méthodes qui, selon vous, ne fonctionnent pas comme vous le souhaitez. Je comprends si la classe est intégrée dans un mécanisme commun, comme par exemple la famille de classes des panneaux de contrôle, où certaines méthodes ne peuvent pas être surchargées à cause des champs qu'elles contiennent dans la section privée de la classe. Mais ici la classe est simple, vous pouvez changer son comportement vous-même. Mais si les développeurs modifient la méthode Open comme décrit ci-dessus, alors la méthode Attach() ne sera pas claire, car il s'agit du graphique actuel ( 0 ). En d'autres termes, le prochain appel de Open aura pour résultatm_chart_id == -1.
En fait, ce n'est pas un problème pour moi, j'ajoute simplement une chaîne qui obtient l'ID du graphique actuel à OnInit et attache le graphique à l'objet de la classe en utilisant la méthode Attach(long chart), mais certains des développeurs qui ne lisent pas cette branche, peuvent avoir des moments étranges.
Oui vous savez, d'une certaine manière, ce que les développeurs veulent changer est clair sans vos explications.
Comment peut-il y avoir des accusations non fondées, et personne ne vous accuse, vous êtes confus.
La mémoire ?
L'utilisateurAlexey Kozitsyn l'utilise mal et obtient un tas de bogues à la sortie...
Et une demande aux développeurs de la bibliothèque standard - faites une description de la structure de la bibliothèque. Beaucoup ne le comprennent pas et commencent à faire des erreurs, tandis que vous suivez leur exemple et brisez tout ce que vous avez fait.
Quelques accusations. Si vous ne considérez pas cela comme une accusation, relisez la définition du mot.
Vous ne voulez pas écrire selon l'idéologie inhérente à labibliothèque standard, surcharger les méthodes qui, selon vous, ne fonctionnent pas comme vous le souhaitez.
Vous êtes notre idéologue, veuillez nous expliquer ce qu'est l'idéologie dans la bibliothèque et comment l'utiliser correctement. Expliquez également pourquoi la méthode portant le nom Open() peut ne rien ouvrir, mais que le graphique actuel sera envoyé au travail. Et vous pensez également être plus intelligent que les développeurs de cette bibliothèque ? Développez la vôtre, avec sa propre idéologie, que vous êtes le seul à comprendre.
Si les développeurs modifient la méthode Open comme décrit ci-dessus, alors la méthode Attach() ne sera pas claire, car il s'agit du graphique actuel ( 0 ). En d'autres termes, le prochain appel à Open aura pour résultatm_chart_id == -1.
Oui, en effet, il est clair sans aucun exemple que vous dites n'importe quoi. Exactement parce que s'il n'y a pas besoin d'ouvrir quoi que ce soit, il n'y a pas non plus de raison d'appeler la méthode Open() ! Comment ne pouvez-vous pas le comprendre ? Ou bien cela ne correspond pas à votre idéologie ?
En fait, cela ne créera aucun problème pour moi, je vais juste ajouter une chaîne à OnInit qui obtient l'ID du graphique actuel et l'attacher à l'objet graphique en utilisant la méthode Attach(long chart), mais certains des développeurs qui ne lisent pas ce fil, peuvent être confus et "inattendus".
Si cela ne vous pose pas de problème, pourquoi s'embêter avec vos messages précédents ? Pourquoi tu fais des histoires ? J'ai signalé la faille aux développeurs, ils vont la corriger. Tout va bien, tout le monde est gagnant. Mais non, vous êtes sorti avec une idéologie que même vous ne pouvez apparemment pas expliquer.
Et oui, si les développeurs tiers ont des problèmes, ils peuvent toujours regarder le code source de la classe et comprendre comment elle fonctionne.
Sur ce point, je pense que notre dialogue peut se terminer. Vous aurez votre opinion et j'aurai la mienne. Et MQ décidera ce qui et comment sera plus logique et correct.