Erreurs, bugs, questions - page 460

[Stanislav Korotky]

voix_kas:

L'EA nécessite l'accès à un indicateur. Vous pouvez l'obtenir d'au moins trois façons : IndicatorCreate(...) ou iCustome(...) ou, s'il s'agit d'un indicateur standard, par exemple, iMA(...).

Si j'ai bien compris, lorsque vous utilisez une variante, vous devez explicitement libérer le handle résultant (IndicatorRelease).

La question porte sur le choix de la manière d'appeler l'indicateur. Quels sont les avantages et les inconvénients de chaque méthode ? Intérêt prioritaire pour la rapidité du traitement.

IndicatorCreate - pour les indicateurs standards, afin que dans le cas du poignet ils soient les analogues de l'appel iMA. iCustom - pour les indicateurs personnalisés "sur mesure". C'est-à-dire des choses essentiellement différentes.

La vitesse d'appel de iMA et IndicatorCreate(IND_MA) devrait être comparable, mais je ne l'ai pas vérifié.

Quant à IndicatorRelease, il est logique de l'appeler si vous n'avez pas besoin de revenir à cet indicateur après le calcul. Je n'ai pas de telles situations - si un indicateur est nécessaire (avec un ensemble donné de paramètres), alors il sera nécessaire pour un calcul/calcul supplémentaire, et si les paramètres d'entrée du script changent, alors tout sera réinitialisé et de nouvelles poignées seront créées.

[Renat Fatkhullin]

En fait, dans 99 % des cas, l'appel à IndicatorRelease est une erreur logique de la part du programmeur.

La création d'un indicateur est l'une des opérations les plus coûteuses, qui déclenche des mécanismes très profonds de leur calcul. Essayer de fermer une poignée d'indicateur est également une opération très coûteuse, si l'on pense aux processus réels de sa mise en œuvre. La création et la fermeture fréquentes d'indicateurs montrent que le développeur ne comprend pas du tout l'essence des opérations.

Il est très facile à comprendre.

[Alexander Puzikov]

Renat:

En fait, dans 99% des cas, appeler IndicatorRelease est une erreur logique de la part du programmeur.

La création d'un indicateur est l'une des opérations les plus coûteuses qui déclenche des mécanismes très profonds pour les calculer. Essayer de fermer une poignée d'indicateur est également une opération très coûteuse si l'on pense aux véritables processus sous-jacents de sa mise en œuvre. La création et la fermeture fréquentes d'indicateurs montrent que le développeur ne comprend pas du tout l'essence des opérations.

Il est très facile à comprendre.

Permettez-moi d'intervenir dans la conversation et de dire : les mécanismes du m-programme, du terminal, du forex (en fait, pourquoi sommes-nous réunis ici)

La raison pour laquelle nous sommes ici est constituée de vérités simples, alors qu'est-ce qui nous empêche de les comprendre et de faucher les roubles - ou le logiciel que nous allons vendre,

Et s'il n'y a aucune possibilité de le faire, nous devons garder le silence jusqu'à ce qu'un "miracle" se produise !

[Renat Fatkhullin]

Im_hungry:

Permettez-moi d'intervenir dans la conversation et de dire : les mécanismes du programme, le terminal, le forex (en gros ce pour quoi nous sommes ici)

Nous devons faire attention à ce que nous faisons et à ce que nous ne voulons pas faire,

Nous devrions garder le silence jusqu'à ce qu'un "miracle" se produise !

Un bel exemple de flot incompréhensible de pensées. J'envie de telles capacités.

[Mykola Demko]

Renat:
Un bel exemple de flux de pensées incompréhensibles. C'est enviable de pouvoir le faire.

Sûrement un Jedi de niveau 80, Maître Yoda médite tranquillement sur la touche :)

Et il n'y a pas de doute, ils "aidaient les enfants sans abri en cas de problème" (à partir de 12 chaires).

[Андрей Павлов]

Il n'y a pas si longtemps, mon code de travail a cessé de se compiler.

C'est la faute au code de la bibliothèque standard:

'GetLastError' - ambiguous call to overloaded function with the same parameters SymbolInfo.mqh  718     10
'GetLastError' - ambiguous call to overloaded function with the same parameters	SymbolInfo.mqh	725	57

Apparemment à cause de ce qu'il y a dans mon code :

#import "kernel32.dll"
uint GetLastError();
#import
.....
kernel32::GetLastError() 
.... 

Comment puis-je "digérer" cela pour que mon programme fonctionne à nouveau ? Je ne suis pas sûr de ce qui a changé dans la nouvelle version de MQL.

Les fonctions importées ne sont-elles pas autorisées à porter le même nom que les fonctions intégrées ? Comment continuer à vivre ?

[---]

7134956:

Comment puis-je "digérer" cela pour que mon programme fonctionne à nouveau ? Je ne comprends pas bien ce qui a changé dans la nouvelle version de MQL.

il suffit d'ajouter un paramètre à l'intérieur

#import "Kernel32.dll"
uint GetLastError(int);
#import

[Андрей Павлов]

sergeev:

ajouter un simple paramètre à l'intérieur

Merci ! Ça semble avoir aidé. Mais c'est une sorte de béquille que de passer un paramètre qui est redondant.

[---]

Voyons cela comme une fonctionnalité ou un autobug.

[TheXpert]

sergeev:
Voyons cela comme une fonctionnalité ou un autobug.

Vous pourriez l'enlever et l'envelopper dans une bibliothèque séparée, en la renommant.

Vous pouvez aussi essayer de demander des espaces nommés, mais c'est probablement inutile.