Errori, bug, domande - pagina 2239

Nuovo commento
 
Stanislav Korotky:

Leggo anche MSDN. Spiega, è che Microsoft non conosce l'inglese o che non leggono la loro stessa documentazione, o l'ultima opzione - le bandiere in MQL hanno un nome simile a WinApi ma funzionano in modo diverso?

Preso da qui - https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-createfilea

FILE_SHARE_READ -Abilita le successive operazioni di apertura su un file o dispositivo per richiedere l'accesso in lettura.Altrimenti, altri processi non possono aprire il file o il dispositivo se richiedono l'accesso in lettura.

FILE_SHARE_WRITE -Abilita le successive operazioni di apertura su un file o dispositivo a richiedere l'accesso in scrittura.Altrimenti, altri processi non possono aprire il file o il dispositivo se richiedono l'accesso in scrittura.

Pertanto, il primo programma ha solo bisogno di impostare FILE_SHARE_READ perché il secondo possa leggere. FILE_SHARE_WRITE solo se sapete che anche il secondo programma scriverà sul file.

Può fare un esempio della differenza di comportamento?


Dal link fornito, la descrizione delle bandiere non dà un'idea di come usarle correttamente quando si cerca di aprire lo stesso file più di una volta.

In base ai dati della tua descrizione, prova a rispondere alla domanda: la quarta (hread_1) e la quinta (hread_2) nell'esempio seguente sarebbero valide?

   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);

Vi dico subito la risposta: queste chiamate non saranno valide

 
Stanislav Korotky:

Leggo anche MSDN. Spiega, è che Microsoft non conosce l'inglese o che non leggono la loro stessa documentazione, o l'ultima opzione - le bandiere in MQL hanno un nome simile a WinApi ma funzionano in modo diverso?

Preso da qui - https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-createfilea

FILE_SHARE_READ -Abilita le successive operazioni di apertura su un file o dispositivo per richiedere l'accesso in lettura.Altrimenti, altri processi non possono aprire il file o il dispositivo se richiedono l'accesso in lettura.

FILE_SHARE_WRITE -Abilita le successive operazioni di apertura su un file o dispositivo a richiedere l'accesso in scrittura.Altrimenti, altri processi non possono aprire il file o il dispositivo se richiedono l'accesso in scrittura.

Pertanto, il primo programma ha solo bisogno di impostare FILE_SHARE_READ perché il secondo possa leggere. FILE_SHARE_WRITE solo se sapete che anche il secondo programma scriverà sul file.

Per evitare confusione con queste bandiere, basta assicurarsi che quando apriamo un file, queste bandiere permettono agli altri processi di leggere e/o scrivere, non a noi stessi.

 
Alexey Viktorov:

Per evitare confusione su questi flag, è importante capire che quando apriamo un file, questi flag permettono agli altri processi di leggere e/o scrivere, non a noi stessi.

È esattamente quello che sto dicendo, è esattamente come capisco la documentazione di MS (in particolare, colui che apre un file per la scrittura può permettere ad altri di condividere la lettura). La tecnica di flagging raccomandata fa il contrario - il secondo processo usa il flag write-share per autorizzare la lettura del file che viene scritto (cioè, in un certo senso, bypassa il primo processo per autorizzare la lettura, anche se il primo processo non ha implementato il permesso di write-share). Questo suona persino innaturale. Comunque, vado a leggere le interpretazioni.

 
Stanislav Korotky:

È esattamente quello che sto dicendo, è così che capisco la documentazione di MS (in particolare, chi apre un file per scrivere può permettere ad altri di leggerlo insieme).

Non solo la lettura può essere permessa, ma anche la scrittura. E se ci sarà qualche scrittura condivisa, ogni processo dovrebbe avere il permesso di scrittura condivisa.

Stanislav Korotky:

L'uso dei flag che è raccomandato per risolvere questo problema presuppone il contrario - che il secondo processo usi il flag di scrittura per autorizzarsi a leggere il file che si sta scrivendo (cioè una sorta di bypassare il primo processo alzando la sua autorizzazione, anche se il primo processo non ha concesso l'accesso in scrittura al file condiviso). Questo suona persino innaturale. Comunque, vado a leggere le interpretazioni.

E questo è sbagliato. Il Sé non permette mai nulla né solleva alcun diritto a se stesso. I flag FILE_SHARE_READ e FILE_SHARE_WRITE si riferiscono agli attributi di un file aperto. Se gli attributi non includono il permesso del processo che ha già il file in uso, il file non può essere usato finché non viene rilasciato.

È così che funziona in questi esempi: Il primo file aperto per la scrittura, permette ad altri processi di leggere, e il secondo quando si apre cerca di vietare (non permette) di scrivere a chi sta già utilizzando il file. Qui è dove diventa una seccatura... È come, chi si è alzato per primo, chi se ne va...

 
Alexey Kozitsyn:

Domanda per gli sviluppatori.

C'è una funzione di sincronizzazione:

A volte ottengo questo errore con esso:

Cioè l'indicatore funziona su USDJPY, e ottengo un errore con il simbolo EURGBP. Allo stesso tempo c'è un grafico EURGBP aperto nel terminale.

L'errore 4014 dice che:

La funzione di sistema non può essere chiamata

Come può essere?

Potrebbe essere che sia stato generato da qualche altra chiamata.

Usare ResetLastError() prima di chiamare SymbolIsSynchronised

 
Slava:

E così è stato generato da qualche altra chiamata.

Usare ResetLastError() prima di chiamare SymbolIsSynchronized

Sì, l'ho già fatto... Si scopre che se non è chiaramente scritto nella documentazione della funzione che GetLastError() deve essere chiamata in caso di errore, significa che la funzione non azzera il codice di errore. Giusto?

 
Slava:

Inoltre, vorrei sapere quali funzioni potrebbero potenzialmente causare questo errore nell'indicatore?

 
A100:
Nel mio caso ServiceDesk ora scrive che non può riprodurre... di conseguenza è necessario l'aiuto della camera... un po' più tardi descriverò in dettaglio cosa e come

Quindi sulla richiesta #1530548 ServiceDesk non può riprodurre l'errore https://www.mql5.com/ru/forum/1111/page1628#comment_2702870 anche se ho una riproduzione costante anche adesso (nella build 1881). Con un po' di riflessione ho capito perché! La risposta è: perché ho un computer lento (tablet)

Ho avuto la stessa situazione nel caso #1952509 con questo problema https://www.mql5.com/ru/forum/1111/page2124#comment_6518537

Anche ServiceDesk ha riferito all'inizio di non poter riprodurre l'errore. Mi ci è voluto molto sforzo per convincermi che c'era un errore dopo tutto... alla fine:

Squadra di supporto 2018.02.10 22:35
Sembra che abbia riprodotto il tuo problema venerdì su una macchina debole con 39 grafici.
Lo terrò d'occhio. Richiederà ulteriori dati se necessario. Grazie.

Questo solleva la domanda: è proprio necessario preoccuparsi di questi errori? O semplicemente lasciarli vivere la loro vita in pace ... forse non salteranno più fuori - è sufficiente avere un computer veloce, giusto?

Queste domande sorgono nel contesto che una dozzina di altri grafici con diversi EAs/indicatori possono trasformare un computer veloce in uno lento (e un trader medio usa esattamente un sacco di EAs - per esempio https://www.mql5.com/ru/forum/267154/page5#comment_8164924 - 82 EAs sono in esecuzione)... O anche un computer lento può diventare lento per un breve periodo a causa di altre circostanze (antivirus... altri programmi... o il sistema stesso ha temporaneamente preso il controllo di quasi tutte le risorse).

E poi esattamente quell'inspiegabile 1 su 100 di fallimento accadrà (e per le leggi della natura avviene naturalmente nel momento più inopportuno).

Ошибки, баги, вопросы
Ошибки, баги, вопросы
  • 2016.08.03
  • www.mql5.com
Общее обсуждение: Ошибки, баги, вопросы
 
A100:

Quindi sulla richiesta #1530548 ServiceDesk non può riprodurre l'errore https://www.mql5.com/ru/forum/1111/page1628#comment_2702870 anche se ho una riproduzione costante anche adesso (nella build 1881). Con un po' di riflessione ho capito perché! La risposta è: perché ho un computer lento (tablet)

La stessa situazione era nella domanda #1952509 per questo problema https://www.mql5.com/ru/forum/1111/page2124#comment_6518537

Anche ServiceDesk ha riferito all'inizio che non poteva riprodurre l'errore. Mi ci è voluto molto sforzo per convincermi che c'era un errore dopo tutto... alla fine:

Squadra di supporto 2018.02.10 22:35
Sembra che abbia riprodotto il tuo problema venerdì su una macchina debole con 39 grafici.
Lo terremo d'occhio. Richiederà ulteriori dati se necessario. Grazie.

Questo solleva la domanda: è proprio necessario preoccuparsi di questi errori? O semplicemente lasciarli vivere la loro vita in pace ... forse non salteranno più fuori - è sufficiente avere un computer veloce, giusto?

Queste domande sorgono nel contesto che una dozzina di altri grafici con diversi EAs/indicatori possono trasformare un computer veloce in uno lento (e un trader medio usa esattamente un sacco di EAs - per esempio https://www.mql5.com/ru/forum/267154/page5#comment_8164924 - 82 EAs sono in esecuzione)... O anche un computer lento può diventare lento per un breve periodo a causa di altre circostanze (antivirus... altri programmi... o il sistema stesso ha temporaneamente preso in consegna quasi tutte le risorse).

E poi esattamente quell'inspiegabile 1 su 100 di fallimento accadrà (e per le leggi della natura avviene naturalmente nel momento più inopportuno).


Non ho un computer debole. Ma questo errore di apertura del file si verifica anche di tanto in tanto.

 
Vladislav Andruschenko:
Non ho un computer debole. Ma questo errore con l'apertura di un file si verifica anche di tanto in tanto.
Tanto più che non sei un utente ordinario, e il tuo lavoro è usato da molte, molte persone
1...223222332234223522362237223822392240224122422243224422452246...3184
Nuovo commento