Erreurs, bugs, questions - page 2654
![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Quelqu'un peut-il nous éclairer sur la question suivante :
J'ai une dll écrite en C# mais compilée :
- Pour le projet MT5 usual C# - Net Framework dll - 64 bit
- MT4 - Net Framework dll - 32 bits, mais enveloppé dans des appels C gérés.
Les sources dll sont 100% identiques, sauf le wrapper MT4 bien sûr,
Système d'exploitation Win10-64
Eh bien, la question est de savoir pourquoi les appels de MT4 fonctionnent exactement 4 fois plus vite, les chiffres sont d'environ 100 000 appels de dll sur MT4 pendant 7,5 secondes, MT5 pendant 30 secondes
IMHO. C-runtime dans un cas et une machine virtuelle dans l'autre.
Une interface graphique est implémentée dans l'Expert Advisor. Les événements utilisateur sont également mis en œuvre (par exemple, les événements de changement de GUI). J'effectue le débogage sur des données réelles (F5). Dès que je place un point d'arrêt sur un événement utilisateur, le débogueur s'arrête, mais le fait d'appuyer ensuite sur F5 (poursuite du débogage) n'entraîne pas de modifications de l'interface graphique elle-même. Question : cela devrait-il être le cas, ou s'agit-il d'un bug du débogueur ?
Si je supprime le point d'arrêt (le débogage continue) - les changements dans l'interface graphique sont normaux.
MT5, build 2340.
IMHO. C-runtime dans un cas et une machine virtuelle dans l'autre.
Il y a un .Net virtuel dans les deux dlls.
j'ai trouvé la différence dans le code, j'ai même lancé la classe de base 32 bits dans un thread séparé, parce qu'elle n'a pas d'autre moyen de fonctionner
J'ai fait les mêmes manipulations pour MT5, les résultats sont plus ou moins les mêmes (trois tests chacun) :
MT5 : cycle 100000 , temps 8.482981 sec , cycle 100000 , temps 8.638789 sec , cycle 100000 , temps 8.390046 sec
MT4 : cycle 100000 , temps 7.128857 sec , cycle 100000 , temps 7.176361 sec , cycle 100000 , temps 7.205439 sec
Salutations ! Joyeuses fêtes à tous les hommes ! !!!
Je ne comprends pas quel est le bug étrange avec l'affichage en zigzag de l'équité dans le testeur. Je ne comprends pas l'étrange bug de l'affichage en zigzag des actions dans le testeur. Si je change le paramètre " Méthode de règlement " de " Stoks d'échange " à " Forex ", l'équité s'affiche normalement. J'ai eu la même expérience il y a quelques années, je voulais essayer de connecter MT5 à un fonds, je l'ai testé, j'ai eu peur et j'ai abandonné. J'ai réessayé et c'est la même chose. C'est étrange ?
Le problème est soluble pour les méthodes des classes conteneurs "typées", mais il ne l'est pas pour les fonctions normales.
La principale contradiction est que pour transférer des structures, il est nécessaire d'utiliser le transfert par référence, et pour les littéraux et les variables temporaires - le transfert par valeur.
En conséquence, nous obtenons une erreur de compilation pour les types lvalue normaux car les deux fonctions surchargées conviennent à l'appel.
Comme solution partielle et uniquement pour les types "primitifs", vous pouvez construire 12 fonctions surchargées :
Mais si une fonction doit accepter deux arguments "universels", seules 144 fonctions surchargées sont nécessaires pour l'implémenter, alors que dans le cas de trois arguments de ce type, l'ensemble des 1728 fonctions surchargées sont nécessaires.
Suggestion :
Enfin, permettez aux utilisateurs de passer des littéraux et des variables temporaires comme arguments de fonction const ref.
Que ce soit une directive séparée - peu importe...
Défauts dans le fonctionnement de la fonction template/class cache :
(non corrigé par MT5(build 2340)) ** Comportement indéfini, vous créez un objet complexe enveloppé avec le type interne "C" plusieurs fois et il s'avère être un type de données complètement différent, peut-être "B", peut-être "int", ce que vous voulez...
(non corrigé par MT5(build 2340)) * Erreur de compilation, bug sur le passage d'un pointeur de fonction comme argument de modèle const ref.
(non corrigé par MT5(build 2340)) * Erreur de compilation, l'objet B<int> peut être créé après l'objet de la classe B<void*>, mais si cela est fait avant, une erreur de compilation se produit.
Défauts dans la fonction de modèle/travail de classe :
(non corrigé par MT5(build 2340)) ** Erreur de compilation, bug à l'intérieur d'une fonction template, le pointeur passé dans une opération deconversion de type explicite se comporte comme une classe, sinon comme un pointeur.
(non corrigé par MT5(build 2340)) ** Erreur de compilation, bogue avec la génération de code de classe modèle lors de l'utilisation de classe interne.
(non corrigé par MT5(build 2340)) ** Erreur de compilation, bogue lors de la tentative d'accès à une classe interne pour un paramètre de modèle de fonction de modèle.
(non corrigé par MT5(build 2340)) ** Erreur de compilation : lors de la génération d'une méthode/classe de modèle, le processus de "remplacement automatique" du paramètre de modèle fait échapper le scop dans le code du programme principal.
(non corrigé par MT5(build 2340)) * Erreur de compilation, le bogue avec la classe template ne générant pas de code automatiquement lorsque la classe template agit comme une valeur de retour pour la méthode template.
(non corrigé par MT5(build 2340)) * Erreur de compilation, bogue dans la définition de la classe interne - il n'y a pas de possibilité de se référer à l'espace de nom global explicitement lors de la spécification de la classe de base.
Défauts dans les priorités d'appel des fonctions surchargées dans MQL par rapport à C++ :
(non corrigé par MT5(build 2340)) *** Erreur de compilation lorsqu'il y a un héritage de classe A <= B <= C <= D et que deux fonctions de surcharge sont implémentées, par exemple, une avec le paramètre A* et une avec le paramètre B*, alors passer dans une telle fonction un objet C* ou D* dans MQL provoque une erreur de compilation "appel ambigu à une fonction surchargée".
(non corrigé par MT5(build 2340)) ** Runtime, non concordance de priorité pour les appels de fonctions de modèle surchargées.
Suggestions :
link- sur l'autorisation de passer des littéraux et des variables temporaires comme arguments de fonction const ref.
lien- lors dudéplacement de fichiers de projet dans l'onglet Projet, pour les fichiers déplacés qui sont ouverts et dans les onglets ME, pour mettre automatiquement à jour leur chemin d'accès.
link- pour introduire la fonctionnalité de déclaration de typedef dans MQL.
lien- sur la possibilité de forcer la génération de constructeurs de copie et d'opérateurs d'affectation par défaut.
Je demande de l'aide, je suis complètement à côté de la plaque.
Dans OnChartEvent, en appuyant sur `C`, j'annule/rétablit le graphique des prix.
Et tout irait bien, mais si la disposition du clavier n'est pas sélectionnée Anglais - ne fonctionne pas.
Comment rendre la détection de l'appui sur la touche "C" indépendante de la mise en page sélectionnée ?
Je demande de l'aide, je suis complètement à côté de la plaque.
Dans OnChartEvent, en appuyant sur `C`, j'annule/rétablit le graphique des prix.
Et tout irait bien, mais si la disposition du clavier n'est pas sélectionnée Anglais - ne fonctionne pas.
Comment faire en sorte que la détection de l'appui sur la touche "C" soit indépendante de la mise en page sélectionnée ?
Nécessité de vérifierlparam
Pour les dispositions de clavier ru et en (minuscules et majuscules), lparam sera 67 :