Erreurs, bugs, questions - page 2238

[TheXpert]

Ilyas:

Il s'agit d'une limitation du système (WinAPI).

Voici les drapeaux corrects pour que votre code fonctionne :

Allez !)

Nous avons vérifié - Windows peut ouvrir le fichier, mais pas le script. Le problème vient de l'indicateur FILE_SHARE_READ.

[Ilyas]

fxsaber:

Veuillez corriger FileLoad

Merci pour cet article.

Ajout des drapeaux FILE_FLAG_SHARE_READ | FILE_FLAG_SHARE_WRITE à l'implémentation de la fonction FileLoad/FileSave

Attention, lorsque l'on écrit et lit le même fichier en même temps, la synchronisation doit être organisée correctement, car le résultat de la lecture sera indéfini.

[fxsaber]

Ilyas:

Merci pour le message.

Ajout des drapeaux FILE_FLAG_SHARE_READ | FILE_FLAG_SHARE_WRITE à l'implémentation de la fonction FileLoad/FileSave

Attention, lorsque l'on écrit et lit le même fichier en même temps, la synchronisation doit être organisée correctement, car le résultat de la lecture sera indéfini.

Merci pour la correction, l'angle de calage ne devrait pas être affecté.

[Ilyas]

TheXpert:

Allez !)

Le problème vient de l'indicateur FILE_SHARE_READ.

Je vous recommande de lire https://docs.microsoft.com/en-us/windows/desktop/FileIO/creating-and-opening-files

[fxsaber]

Ilyas:

Je vous recommande de lire https://docs.microsoft.com/en-us/windows/desktop/FileIO/creating-and-opening-files

Comment faire face à ce fait ?

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

Bugs, bugs, questions

fxsaber, 2018.07.23 16:48

Il s'agit manifestement d'un bug, car avec de tels drapeaux, les applications tierces lisent le fichier sans aucun problème.

Ces fichiers.

FILE_READ | FILE_WRITE | FILE_IS_TEXT | FILE_SHARE_READ

Je visualise dans TotalCommander sans FileClose. Sans FILE_SHARE_READ, cela ne fonctionne pas.

[TheXpert]

Ilyas:

Je recommande de le lire

Oui, j'étais sur le point de le faire.

J'admets que j'avais tort. Si le premier handle est ouvert à l'écriture, le second doit ajouter le drapeau FILE_SHARE_WRITE.

mais il y a un autre commentaire de l'a100 qui n'a pas de dossier du tout

[Stanislav Korotky]

Ilyas:

L'ouvreur ne peut pas utiliser l'indicateur FILE_SHARE_WRITE (autoriser l'écriture) pour la lecture, car il y a un écrivain.

Il s'agit d'une limitation du système (WinAPI).

Voici les drapeaux corrects pour lesquels votre code fonctionnera :

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 est-ce la dernière option - les drapeaux dans MQL sont nommés de manière similaire à WinApi mais fonctionnent d'une manière différente ?

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 ne doit être défini que si l'on sait que le second programme écrira également dans le fichier.

[[Supprimé]]

Question pour les développeurs.

Il existe une fonction de synchronisation :

//+------------------------------------------------------------------+
//| Проверка синхронизации символов                                                                                             |
//+------------------------------------------------------------------+
bool CheckSync()
        {
         //--- Проверка синхронизации символов
         if( !SymbolIsSynchronized( inpSymbol_1 ) )
                {
                 Print( __FUNCTION__,": ОШИБКА #",GetLastError(),": SymbolIsSync("+inpSymbol_1+") = false!" );
                 return( false );
                }
         if( !SymbolIsSynchronized( inpSymbol_2 ) )
                {
                 Print( __FUNCTION__,": ОШИБКА #",GetLastError(),": SymbolIsSync("+inpSymbol_2+") = false!" );
                 return( false );
                }
         //--- Если символы синхронизированы
         return( true );
        }

J'obtiens parfois cette erreur avec elle :

2018.07.24 15:14:27.415 Indicator (USDJPY,M5)   CheckSync: ОШИБКА #4014:  SymbolIsSync(EURGBP) = false!

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 ?

[A100]

TheXpert:

Oui, j'étais sur le point de le faire.

J'admets que j'avais tort. Si le premier handle est ouvert en écriture, le second doit ajouter l'indicateur FILE_SHARE_WRITE.

mais il y a aussi un commentaire de l'a100 qui n'a pas d'enregistrement du tout.

Dans mon cas, ServiceDesk écrit maintenant qu'il ne peut pas jouer... besoin de l'aide de la salle ... plus tard je décrirai comment le faire ...

[Ilyas]

Stanislav Korotky:

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.

Pouvez-vous donner un exemple de la différence de comportement ?

Dans le lien fourni, la description des drapeaux ne donne pas une idée de la manière de les utiliser correctement lorsqu'on essaie d'ouvrir le même fichier plusieurs fois.

En vous basant sur les données de votre description, essayez de répondre à la question suivante : les quatrième (hread_1) et cinquième (hread_2) de l'exemple ci-dessous seraient-ils valides ?

   HANDLE hwrite     =::CreateFile(L"test.txt", GENERIC_WRITE,FILE_SHARE_READ,                   nullptr,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,nullptr);

   HANDLE hread_fail =::CreateFile(L"test.txt", GENERIC_READ, FILE_SHARE_READ,                   nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);
   HANDLE hread_ok   =::CreateFile(L"test.txt", GENERIC_READ, FILE_SHARE_WRITE,                  nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);

   HANDLE hread_1    =::CreateFile(L"test.txt", GENERIC_READ, FILE_SHARE_WRITE,                  nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);
   HANDLE hread_2    =::CreateFile(L"test.txt", GENERIC_READ, FILE_SHARE_WRITE|FILE_SHARE_READ,  nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);

Je vais vous donner la réponse tout de suite : ces appels ne seront pas valables.