Erreurs, bugs, questions - page 2239
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
Je lis aussi MSDN. Expliquez, est-ce que Microsoft ne connaît pas l'anglais ou qu'ils ne lisent pas leur documentation eux-mêmes, ou la dernière option - les drapeaux dans MQL sont nommés de manière similaire à WinApi mais fonctionnent différemment ?
Tiré d'ici - https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-createfilea
FILE_SHARE_READ -Permet aux opérations d'ouverture ultérieures sur un fichier ou un périphérique de demander un accès en lecture.Sinon, les autres processus ne peuvent pas ouvrir le fichier ou le périphérique s'ils demandent un accès en lecture.
FILE_SHARE_WRITE -Permet aux opérations d'ouverture ultérieures sur un fichier ou un périphérique de demander un accès en écriture.Sinon, les autres processus ne peuvent pas ouvrir le fichier ou le périphérique s'ils demandent un accès en écriture.
Par conséquent, il suffit au premier programme de définir FILE_SHARE_READ pour que le second puisse lire. FILE_SHARE_WRITE uniquement si vous savez que le second programme écrira également dans le fichier.
Pour éviter toute confusion avec ces drapeaux, assurez-vous simplement que lorsque nous ouvrons un fichier, ces drapeaux permettent aux autres processus de lire et/ou d'écrire, et non à nous-mêmes.
Pour éviter toute confusion à propos de ces drapeaux, il est important de comprendre que lorsque nous ouvrons un fichier, ces drapeaux permettent aux autres processus de lire et/ou d'écrire, pas à nous-mêmes.
C'est exactement ce que je dis, c'est exactement comme ça que je comprends la documentation de MS (en particulier, celui qui ouvre un fichier en écriture peut permettre aux autres de partager la lecture). La technique de marquage recommandée fait le contraire : le second processus utilise le drapeau de partage d'écriture pour autoriser la lecture du fichier en cours d'écriture (c'est-à-dire qu'il contourne en quelque sorte le premier processus pour autoriser la lecture, même si le premier processus n'a pas mis en œuvre la permission de partage d'écriture). Cela semble même contre nature. Bref, je vais lire les interprétations.
C'est exactement ce que je dis, c'est comme ça que je comprends la documentation MS (en particulier, celui qui ouvre un fichier en écriture peut permettre aux autres de le lire ensemble).
Non seulement la lecture peut être autorisée, mais aussi l'écriture. Et s'il y a une écriture partagée, chaque processus doit avoir une permission d'écriture partagée.
L'utilisation des drapeaux qui est recommandée pour résoudre ce problème suppose le contraire - que le second processus utilise le drapeau d'écriture pour s'autoriser à lire le fichier en cours d'écriture (c'est-à-dire qu'il contourne en quelque sorte le premier processus en levant son autorisation, même si le premier processus n'a pas accordé l'accès en écriture au fichier partagé). Cela semble même contre nature. Bref, je vais lire les interprétations.
Et c'est faux. Le moi ne permet jamais rien et n'élève aucun droit sur lui-même. Les drapeaux FILE_SHARE_READ et FILE_SHARE_WRITE font référence aux attributs d'un fichier ouvert. Si les attributs n'incluent pas la permission du processus qui a déjà le fichier en cours d'utilisation, le fichier ne peut pas être utilisé jusqu'à ce qu'il soit libéré.
C'est ainsi que cela fonctionne dans ces exemples : Le premier ouvre le fichier pour l'écriture, permet aux autres processus de lire, et le second lorsque vous l'ouvrez essaie d'interdire (ne pas permettre) d'écrire à celui qui utilise déjà le fichier. C'est là que ça se gâte... C'est comme, qui s'est levé en premier, qui s'en va...
Question pour les développeurs.
Il existe une fonction de synchronisation :
J'obtiens parfois cette erreur avec elle :
C'est-à-dire que l'indicateur fonctionne sur USDJPY, et je reçois une erreur avec le symbole EURGBP. En même temps, il y a un graphique EURGBP ouvert dans le terminal.
L'erreur 4014 dit que :
La fonction système n'est pas autorisée à être appelée
Comment est-ce possible ?
Il se peut qu'il ait été généré par un autre appel.
Utiliser ResetLastError() avant d'appeler SymbolIsSynchronised
Et donc il a été généré par un autre appel.
Utiliser ResetLastError() avant d'appeler SymbolIsSynchronized
Oui, je l'ai déjà fait... Il s'avère que s'il n'est pas clairement écrit dans la documentation de la fonction que GetLastError() doit être appelée en cas d'erreur, cela signifie que la fonction ne réinitialise pas le code d'erreur. N'est-ce pas ?
De plus, j'aimerais savoir quelles fonctions pourraient potentiellement causer cette erreur dans l'indicateur ?
Dans mon cas, ServiceDesk écrit maintenant qu'il ne peut pas jouer... en conséquence, l'aide de la salle est nécessaire ... un peu plus tard, je décrirai en détail ce et comment
Ainsi, pour la demande #1530548 , le ServiceDesk ne peut pas reproduire l'erreur https://www.mql5.com/ru/forum/1111/page1628#comment_2702870 alors que j'ai une lecture régulière même maintenant (dans la version 1881). Avec un peu de réflexion, j'ai compris pourquoi ! La réponse est : parce que j'ai un ordinateur lent (tablette).
J'ai eu la même situation dans le cas #1952509 avec ce problème https://www.mql5.com/ru/forum/1111/page2124#comment_6518537.
ServiceDesk a également signalé dans un premier temps qu'il ne pouvait pas reproduire l'erreur. Il m'a fallu beaucoup d'efforts pour me convaincre qu'il y avait une erreur après tout... à la fin :
Équipe de soutien 2018.02.10 22:35
Il semble avoir reproduit votre problème vendredi dernier sur une machine faible avec 39 cartes.
Je garderai un œil dessus. Demandera des données supplémentaires si nécessaire. Merci.
Cela soulève la question suivante : est-il vraiment nécessaire de s'occuper de ces erreurs? Ou bien laissez-les vivre leur vie en paix... peut-être qu'ils ne réapparaîtront pas - il suffit d'avoir un ordinateur rapide, non ?
Ces questions se posent dans le contexte où une douzaine d'autres graphiques avec plusieurs EAs/indicateurs peuvent transformer un ordinateur rapide en un ordinateur lent (et un trader moyen utilise exactement beaucoup d'EAs - par exemple https://www.mql5.com/ru/forum/267154/page5#comment_8164924 - 82 EAs sont en cours d'exécution)... Ou encore, un ordinateur lent peut le devenir pendant une courte période en raison d'autres circonstances (antivirus... d'autres programmes... ou le système lui-même a temporairement pris le contrôle de presque toutes les ressources).
C'est alors que se produira cet échec inexpliqué d'une fois sur cent (et selon les lois de la nature, il se produit naturellement au moment le plus inopportun).
Ainsi, pour la demande #1530548 , le ServiceDesk ne peut pas reproduire l'erreur https://www.mql5.com/ru/forum/1111/page1628#comment_2702870 alors que j'ai une lecture régulière même maintenant (dans la build 1881). Avec un peu de réflexion, j'ai compris pourquoi ! La réponse est : parce que j'ai un ordinateur lent (tablette).
La même situation s'est présentée dans l'application #1952509 pour ce problème https://www.mql5.com/ru/forum/1111/page2124#comment_6518537.
ServiceDesk a également signalé dans un premier temps qu'il ne pouvait pas reproduire l'erreur. Il m'a fallu beaucoup d'efforts pour me convaincre qu'il y avait une erreur après tout... à la fin :
Équipe de soutien 2018.02.10 22:35
Il semble avoir reproduit votre problème vendredi dernier sur une machine faible avec 39 cartes.
Nous garderons un œil dessus. Demandera des données supplémentaires si nécessaire. Merci.
Cela soulève la question suivante : est-il vraiment nécessaire de s'occuper de ces erreurs? Ou bien laissez-les vivre leur vie en paix... peut-être qu'ils ne réapparaîtront pas - il suffit d'avoir un ordinateur rapide, non ?
Ces questions se posent dans le contexte où une douzaine d'autres graphiques avec plusieurs EAs/indicateurs peuvent transformer un ordinateur rapide en un ordinateur lent (et un trader moyen utilise exactement beaucoup d'EAs - par exemple https://www.mql5.com/ru/forum/267154/page5#comment_8164924 - 82 EAs sont en cours d'exécution)... Ou encore, un ordinateur lent peut le devenir pendant une courte période en raison d'autres circonstances (antivirus... d'autres programmes... ou le système lui-même a temporairement pris le contrôle de presque toutes les ressources).
Et c'est alors que se produira cet échec inexpliqué d'une fois sur cent (et selon les lois de la nature, il se produit naturellement au moment le plus inopportun).
Je n'ai pas un ordinateur faible. Mais cette erreur d'ouverture de fichier se produit aussi de temps en temps.
Je n'ai pas un ordinateur faible. Mais cette erreur d'ouverture de fichier se produit aussi de temps en temps.
En outre, vous n'êtes pas un utilisateur ordinaire, mais vos œuvres sont utilisées par de très nombreuses personnes.
Je le dirais comme ça :
Lors de la lecture d'un fichier, cette erreur peut se produire 1 fois sur 100 lectures (en lisant un fichier, par exemple, 10 fois par seconde).
De plus, une telle erreur se produit, puis disparaît et le conseiller expert continue de fonctionner.