Dans MQL5, il y a toujours de la place pour un exploit ! ;) - page 9
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
Alexey, tu devrais aussi me dire comment envelopper des tableaux, émis par la fonction OnCalculate(), dans une classe - dans ce cas, on ne peut pas se passer de copier des pointeurs.
Pour le moment, je ne fais que copier des données dans mon tableau de classe, puis je tire un pointeur vers cet objet. Mais cela nécessiterait une copie supplémentaire, qui, comme je le vois, ajoute une "lourdeur" assez notable avec des ticks fréquents et un grand nombre de graphiques. Je veux me débarrasser de cette copie. Mais, à part une béquille via DLL (standard ou auto-écrite), il n'y a rien que je puisse suggérer.
Dans le Service Desk, on me renvoie sans cesse en disant "l'objet peut être supprimé". Mais ce sont leurs propres tableaux ! Lorsque je dis que je peux créer un objet puis le supprimer et que le pointeur deviendra invalide, ils répondent que "c'est moi qui en serai responsable". C'est la "double moralité" à l'œuvre.
Et au diable cette DLL - mais de tels indicateurs nécessitent une confirmation constante au démarrage - ce qui est très perturbant...
A propos de l'option de confirmation. Il faut le faire une fois dans le filet du terminal, n'est-ce pas ? Où est la "confirmation permanente" ici ?
Si l'un est un fer, j'ai un antidote... un indicateur qui va dans les paramètres du MT et vérifie la case... C'est vrai, cet outil devrait aussi être importé en premier )))).
A propos de l'"objet" et du Service Desk. L'objet dans MT est une notion subjective. Pour le programmeur MQL, l'objet est quelque chose qui est attrapé par l'éboueur lorsqu'il y a une fuite.
Quelque chose qui est créé par un allocateur MQL légitime.
D'un point de vue WinAPI ou cloche de processus, cet allocateur lui-même et toute zone d'exécution "statique" d'un indicateur/expert et le hérisson avec lui, est aussi un objet.
Un objet qui se trouve quelque part dans la hanche MT avec les fenêtres, les fils et le bouton "fermer".
D'où la moralité ambiguë, d'où un certain nombre de restrictions MQL qui ne permettent pas de travailler à l'aide de pointeurs réels, d'adresses mémoire, de crochets, en greffant toutes sortes d'écueils.
Mon avis, les gars ont permis l'importation de Dll pour rien. C'est probablement la plus grande douleur dans le cou maintenant. D'une part, les programmeurs MQL demandent plus de puissance, mais d'autre part, le terminal lui-même doit rester un produit monolithique. Pas une gaufre à la merci de divers mods et patchs de scribes.
Je ne considère pas que ce soit un péché d'importer une dll qui est déjà tirée par le terminal en l'état.
A propos de l'option de confirmation. Il faut le faire une fois dans les configurations du terminal, n'est-ce pas ? Où est la "confirmation permanente" ici ?
Si l'un est un fer, j'ai un antidote... un indicateur qui va dans les paramètres du MT et vérifie la case... C'est vrai, cet outil devrait aussi être importé en premier )))).
À propos de l'"objet" et du Service Desk. L'objet dans MT est une notion subjective. Pour le programmeur MQL, l'objet est quelque chose qui est attrapé par l'éboueur lorsqu'il y a une fuite.
Quelque chose qui est créé par un allocateur MQL légitime.
D'un point de vue WinAPI ou cloche de processus, cet allocateur lui-même et toute zone d'exécution "statique" d'un indicateur/expert et le hérisson avec lui, est aussi un objet.
Un objet qui se trouve quelque part dans la hanche MT avec les fenêtres, les fils et le bouton "fermer".
D'où la moralité ambiguë, d'où un certain nombre de restrictions MQL qui ne permettent pas de travailler à l'aide de pointeurs réels, d'adresses mémoire, de crochets, en greffant toutes sortes d'écueils.
Mon avis, les gars ont permis l'importation de Dll pour rien. C'est probablement la dent la plus douloureuse maintenant. D'une part, les programmeurs MQL demandent plus de puissance, mais d'autre part, le terminal lui-même doit rester un produit monolithique. Pas une gaufre à la merci de divers mods et patchs de scribes.