Erreurs, bugs, questions - page 2541

Nouveau commentaire
 
TheXpert:

Je ne veux pas que des personnes incompétentes comme vous, Fedoseyev, etc. soient impliquées dans la discussion des bugs et des constructions.

de sorte que les constructions et les mécanismes pris dans MQL à partir de C++ dans leur intégralité et ayant la même apparence que dans C++ fonctionneraient de la même manière que dans C++.

C'est des conneries et tu le sais, mais tu dois le dire.

C'est vous qui pleurnichez pour dire que c'est ennuyeux, qu'il faut une langue et un fil de discussion séparés.

Ouvrez un fil séparé pour vous et vos sympathisants et pleurnichez-y.

J'avais une meilleure opinion de toi. Mon erreur. Ça arrive. Tu es rustre et... pas intelligent.

 
Roman:

Il est fait pour l'exemple, alors que devrait être exécuté dans un thread séparé, afin de ne pas bloquer le thread mql.
J'obtiens le même comportement lorsque je démarre dans un autre thread, le problème est dans DLL_PROCESS_DETACH, cet identifiant ne fonctionne pas, pour le flag Detach existant.
Oui, nous avons déjà écrit, que nous devons créer une fonction exportée séparée et l'utiliser pour contrôler ce drapeau.
Mais comme le montre cet exemple, l'indicateur dans DLL_PROCESS_DETACH ne fonctionne pas.
S'il y a une erreur dans le terminal, il est logique que DLL_PROCESS_DETACH transfère le drapeau vers un autre état.
La boucle while obtient cet état, sort de la boucle, tout ce qui est rencontré en cours de route est exécuté et termine la fonction Fn() elle-même.
Ce n'est qu'après cela que la dll doit être déchargée !
Mais ce n'est pas le cas, nous avons une sorte de déchargement anticipé des dll par des mécanismes cachés du terminal, et nous avons donc un crash.

Laissez-moi deviner. Si vous lancez une boucle dans un thread du terminal à partir de dll, elle se bloque, et si vous l'exécutez dans un thread séparé, auquel vous détachez(), alors le terminal se bloque avec une erreur ?
 
Roman:

Le fait de ne pas reprendre le contrôle n'est qu'un exemple. Il est clair que l'exécution de while doit se faire dans un thread séparé afin de ne pas bloquer le thread.

Donnez-nous un exemple concret et laissez les pièces jointes tranquilles. Gérez vous-même la création et la suppression des fils de discussion de manière explicite.
 

Forum sur le trading, les systèmes de trading automatisé et les tests de stratégies de trading

Bugs, bugs, questions

Sergey Dzyublik, 2019.05.26 15:12

Malheureusement, à l'heure actuelle, les types de pointeurs de fonction dans MT4/MT5 sont très limités et peu pratiques en raison de certains défauts :
#(non corrigé dans MT5(build 2118))"Erreur de compilation lors de l'utilisation répétée de la même signature de fonction dans un typedef".
#(non corrigé dans MT5(build2118))"Lors du travail avec typedef, l'utilisation d'une fonction template avec une spécialisation explicite ne génère pas de code pour cette fonction template".


Compte tenu de l'implémentation en cours de l'espace de noms, veuillez envisager d'implémenter la prise en charge de ce comportement dans le cadre des corrections de défauts dans le prochain C++:
//#include <iostream>

template<typename T>
class A{
public:
    typedef void (*callback)(T&);   //class namespace for function pointer type
    callback f_ptr;
    T data;
};

template<typename T>
class B{
public:
    typedef void (*callback)(T&);   //class namespace for function pointer type
    callback f_ptr;
};

template<typename T>
void func(T& value){
    ++value;
}


void OnStart(){
//int main(){
    A<int> a;
    B<int> b;
    
    a.f_ptr = func<int>;      // automatic code generation of templates functions
    b.f_ptr = a.f_ptr;        // assignment operation for function pointers with the same function signatures and different function pointer types.
    
    int x = 1;
    b.f_ptr(x);
    printf("%d\r\n", x);                  //2
    printf("%d\r\n", b.f_ptr == a.f_ptr); //1     // equal operation for function pointers with the same function signatures and different function pointer types.
}

MT5 (build 2118), Combien de temps pouvons-nous encore attendre pour des corrections de bugs dans la fonctionnalitétypedef?
Quelques absurdités - un pas à gauche d'un exemple primitif sur l'utilisation detypedef et c'est tout -un tas de bugs bloquant le développement futur.

 
Vladimir Simakov:
Laissez-moi deviner. Si vous exécutez une boucle de dll dans un thread du terminal, elle se bloque, mais si vous l'exécutez dans un thread séparé auquel vous détachez(), le terminal se bloque avec une erreur ?

Pas exactement.
Le lancement d'une boucle fonctionne bien.
Le problème se pose lorsque l'on arrête de force le programme et que l'on passe un drapeau à la boucle pour sortir de la boucle et terminer une fonction en cours d'exécution.
Mais le terminal ne permet pas de sortir de la boucle et de terminer correctement la fonction en cours d'exécution, car le déchargement anticipé de la dll est déjà déclenché. On a un blocage.
La dll est déchargée avant que l'état du drapeau soit passé et la fonction Fn ne se termine pas, le déchargement précoce casse tout.

Je l'ai fait dans un thread terminal par exemple, pour éviter d'écrire tout le code, car en mode bloquant on voit mieux le problème.
J'ai créé une fonction distincte pour le drapeau de boucle et la boucle en cours d'exécution s'exécute dans un thread différent, mais le même comportement.
Et lorsque j'essaie de faire passer le drapeau à un autre état à partir d'un code mql non verrouillé, via une fonction de sortie de la boucle,
le terminal n'attend pas que la boucle en cours d'exécution se termine, et ne laisse pas la fonction Fn se terminer là où la boucle est en cours d'exécution.
Le terminal effectue immédiatement un déchargement anticipé de dll sans attendre la fin de la fonction Fn. C'est là le problème.

LeXpert:
alors donnez un exemple approprié tout de suite. et laissez l'attachi detachi tranquille. contrôlez la création/suppression des fils de discussion explicitement vous-même.

Vous pouvez mieux voir le problème en mode verrouillé. Ce qui change l'état du drapeau n'a pas vraiment d'importance. Avec un point d'entrée ou une fonction séparée.
Le point d'entrée est meilleur pour le mode verrouillé, puisque le contrôle n'est pas retransmis et que la fonction de changement de drapeau ne peut pas être appelée. C'est pourquoi l'atachi detechi est utilisé comme exemple.
Atachi détachable laissé seul, fait une fonction séparée comme vous l'avez conseillé, pas de chance, sur un projet en cours en mode non bloquant, même comportement.
La dll est déchargée trop tôt, la fonction en cours d'exécution avec la boucle while n'a pas le temps de se terminer et se bloque.

 
Roman:

La dll est déchargée trop tôt, une fonction en cours d'exécution avec une boucle while n'a pas le temps de se terminer et un blocage se produit.

il ne peut y avoir de blocage dans une mise en œuvre normale

 

Quelqu'un a-t-il rencontré le problème suivant avec les symboles personnalisés ? La fonction CustomRatesUpdate reçoit des cotations normales, mais en fait le graphique et la fenêtre de données contiennent quelque chose d'étrange (dans ce cas les valeurs de clôture et de bas sont 100 fois inférieures à celles passées) :

Aussi, en parallèle, les ticks simples sont émulés avec CustomTicksAdd avec les mêmes valeurs de prix de clôture que dans le log (immédiatement avant CustomRatesUpdate), c'est-à-dire qu'il n'est pas clair d'où viennent les valeurs réduites entre guillemets.

UPD :

J'ai une situation "inverse" sur USDCAD - les cotations augmentent 10 fois après l'écriture. Voici le journal que je reçois :

2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1)                  [time]  [open]  [high]   [low] [close] [tick_volume] [spread] [real_volume]
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) [0] 2019.08.23 00:02:00 1.32987 1.32987 1.32980 1.32987           457       48             0
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) Retry: 1 0
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1)                  [time]  [open]   [high]   [low]  [close] [tick_volume] [spread] [real_volume]
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) [0] 2019.08.23 00:02:00 1.32980 13.29730 1.32980 13.29730           457       52             0

Le premier ArrayPrint est ce qui a été écrit dans CustomRatesUpdate, et le second ArrayPrint est ce qui a été lu en utilisant CopyRates à partir de la dernière barre la plus récente immédiatement après l'écriture. Tout d'abord, la différence est le dernier chiffre de l'ouverture, mais plus important encore, le sommet et la clôture sont augmentés d'un facteur 10.

 
Stanislav Korotky:

Quelqu'un a-t-il rencontré le problème suivant avec les symboles personnalisés ? La fonction CustomRatesUpdate reçoit des cotations normales, mais en fait le graphique et la fenêtre de données contiennent quelque chose d'étrange (dans ce cas les valeurs de clôture et de bas sont 100 fois inférieures à celles passées) :

De plus, les ticks simples sont émulés en parallèle en utilisant CustomTicksAdd avec les mêmes valeurs de prix de clôture que dans le journal (immédiatement avant CustomRatesUpdate), c'est-à-dire qu'il n'est pas clair d'où proviennent les valeurs réduites dans les cotations.

Oui, je l'ai rencontré, seulement mon null n'était pas clair. Tu as 100 fois plus de pointes.
J'ai fait une vérification supplémentaire du zéro, ça n'a pas aidé, ça fonctionnait de travers, puis ça dessinait de tels pics.
Ce comportement a surtout été observé au premier démarrage du programme, et au premier démarrage les fichiers d'historique ont été créés avec une date inexistante.
Nettoyé le dossier ticks, corrigé le code, afin de trouver où le bug, ennuyé, reporté pour le moment, mais aussi doivent revenir à ce problème ((
Vérifiez également l'historique du dossier personnalisé, il peut y avoir des fichiers avec une date qui n'existe pas ;)))
En général, l'insecte y vit de manière spécifique.

Veuillez reproduire le problème dans ce fil de discussion
Je crois que Slava s'occupe des personnages personnalisés là-bas.
Pour rappeler le problème.
 

Cette erreur a-t-elle déjà été mentionnée ? Je ne le trouve pas. En résumé, lors du chargement des résultats d'optimisation à partir du fichier de cache, les résultats avant sont affichés de manière incorrecte. Les valeurs des paramètres ont des chiffres erronés.

Vous allez dans l'onglet d'optimisation. Sélectionnez le conseiller expert. Sélectionnez l'une des optimisations précédentes. Les backtests sont chargés normalement. Les attaquants donnent ça :



MT5, dernière version. x64.

 
Comment se fait-il que lorsque j'éteins l'ordinateur et que j'entre dans MT4 le lendemain, les niveaux ne sont pas enregistrés ?
1...253425352536253725382539254025412542254325442545254625472548...3184
Nouveau commentaire