Erros, bugs, perguntas - página 2239

Novo comentário
 
Stanislav Korotky:

Eu também li MSDN. Explique, será que a Microsoft não sabe inglês ou eles próprios não lêem a sua documentação, ou a última opção - as bandeiras em MQL têm um nome semelhante ao WinApi mas funcionam de forma diferente?

Extraído daqui - https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-createfilea

FILE_SHARE_READ -Permite operações subsequentes abertas num ficheiro ou dispositivo para solicitar acesso de leitura.Caso contrário, outros processos não podem abrir o ficheiro ou dispositivo se solicitarem acesso de leitura.

FILE_SHARE_WRITE -Permite operações abertas subsequentes num ficheiro ou dispositivo para solicitar acesso de escrita.Caso contrário, outros processos não podem abrir o ficheiro ou dispositivo se solicitarem acesso de escrita.

Portanto, o primeiro programa só precisa de definir FILE_SHARE_READ para que o segundo seja lido. FILE_SHARE_WRITE apenas se souber que o segundo programa também irá escrever para o ficheiro.

Pode dar um exemplo da diferença de comportamento?


A partir da ligação fornecida, a descrição das bandeiras não dá uma ideia de como utilizá-las correctamente ao tentar abrir o mesmo ficheiro mais de uma vez.

Com base nos dados da sua descrição, tente responder à pergunta, seriam válidos o quarto (hread_1) e o quinto (hread_2) no exemplo abaixo?

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

Digo-lhe já a resposta: estas chamadas serão inválidas

 
Stanislav Korotky:

Eu também li MSDN. Explique, será que a Microsoft não sabe inglês ou eles próprios não lêem a sua documentação, ou a última opção - as bandeiras em MQL têm um nome semelhante ao WinApi mas funcionam de forma diferente?

Extraído daqui - https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-createfilea

FILE_SHARE_READ -Permite operações subsequentes abertas num ficheiro ou dispositivo para solicitar acesso de leitura.Caso contrário, outros processos não podem abrir o ficheiro ou dispositivo se solicitarem acesso de leitura.

FILE_SHARE_WRITE -Permite operações abertas subsequentes num ficheiro ou dispositivo para solicitar acesso de escrita.Caso contrário, outros processos não podem abrir o ficheiro ou dispositivo se solicitarem acesso de escrita.

Portanto, o primeiro programa só precisa de definir FILE_SHARE_READ para que o segundo seja lido. FILE_SHARE_WRITE apenas se souber que o segundo programa também irá escrever para o ficheiro.

Para evitar confusão com estas bandeiras, basta certificar-se de que quando abrimos um ficheiro, estas bandeiras permitem que outros processos leiam e/ou escrevam, não nós próprios.

 
Alexey Viktorov:

Para evitar confusão sobre estas bandeiras, basta compreender firmemente que quando abrimos um ficheiro, estas bandeiras permitem que outros processos leiam e/ou escrevam, não nós próprios.

É exactamente isso que estou a dizer, é exactamente assim que entendo a documentação da EM (em particular, aquele que abre um ficheiro para escrita pode permitir que outros partilhem a leitura). A técnica de marcação recomendada faz o contrário - o segundo processo utiliza a marcação write-share para autorizar a leitura do ficheiro a ser escrito (ou seja, ultrapassa o primeiro processo para autorizar a leitura, mesmo que o primeiro processo não tenha implementado a permissão write-share). Isto parece mesmo não natural. De qualquer modo, vou ler as interpretações.

 
Stanislav Korotky:

É exactamente isso que estou a dizer, é assim que entendo a documentação da EM (em particular, quem abre um ficheiro para escrita pode permitir que outros o leiam em conjunto).

Não só a leitura pode ser permitida, mas também a escrita. E se houver alguma escrita partilhada, cada processo deverá ter permissão de escrita partilhada.

Stanislav Korotky:

A utilização de bandeiras, que é recomendada para resolver este problema, pressupõe o contrário - que o segundo processo utiliza a bandeira de escrita para se autorizar a ler o ficheiro a ser escrito (ou seja, ultrapassa o primeiro processo ao levantar a sua autorização, mesmo que o primeiro processo não tenha especificado a permissão de escrita de partilha). Isto parece mesmo não natural. De qualquer modo, vou ler as interpretações.

E isto está errado. O self nunca permite nada ou levanta quaisquer direitos a si próprio. As bandeiras FILE_SHARE_READ e FILE_SHARE_WRITE referem-se a atributos de um ficheiro aberto. Se os atributos não incluírem a permissão do processo que já detém o ficheiro, o ficheiro não pode ser utilizado até ser libertado.

É assim que funciona nesses exemplos: O primeiro ficheiro aberto para escrita, permite a leitura de outros processos, e o segundo quando se abre tenta proibir (não permitir) a escrita àquele que já está a utilizar o ficheiro. É aqui que fica um aborrecimento... É como, quem se levantou primeiro, quem se afasta...

 
Alexey Kozitsyn:

Pergunta para os criadores.

Existe uma função de sincronização:

Por vezes, recebo este erro com ele:

Isto é, o indicador corre em USDJPY, e recebo um erro com o símbolo EURGBP. Ao mesmo tempo, há um gráfico EURGBP aberto no terminal.

O erro 4014 diz isso:

A função do sistema não pode ser chamada

Como pode ser?

Pode ser que tenha sido gerado por outra chamada.

Use ResetLastError() antes de chamar SymbolIsSynchronised

 
Slava:

E assim foi gerado por alguma outra chamada.

Use ResetLastError() antes de chamar SymbolIsSynchronized

Sim, eu já o fiz... Acontece que se não estiver claramente escrito na documentação da função que GetLastError() deve ser chamada em caso de erro, isso significa que a função não reinicia o código de erro. Certo?

 
Slava:

Além disso, gostaria de saber que funções poderiam potencialmente causar este erro no indicador?

 
A100:
No meu caso, o ServiceDesk escreve agora que não pode tocar... em conformidade, é necessária a ajuda da sala ... um pouco mais tarde descreverei em pormenor o quê e como

Assim, a pedido #1530548 ServiceDesk não pode reproduzir o erro https://www.mql5.com/ru/forum/1111/page1628#comment_2702870 mesmo que eu tenha uma reprodução estável mesmo agora (na construção 1881). Com um pouco de reflexão, descobri porquê! A resposta é: porque tenho um computador lento (tablet)

Tive a mesma situação no caso #1952509 com este problema https://www.mql5.com/ru/forum/1111/page2124#comment_6518537

O ServiceDesk também informou no início que não conseguia reproduzir o erro. Foi preciso um grande esforço para me convencer de que afinal houve um erro. no final:

Equipa de Apoio 2018.02.10 22:35
Parece ter reproduzido o seu problema na sexta-feira, numa máquina fraca com 39 gráficos.
Ficaremos atentos a isso. Solicitará dados adicionais, se necessário. Obrigado.

Isto levanta a questão: será necessário preocupar-se com tais erros? Ou apenas deixá-los viver em paz... talvez não voltem a aparecer - basta ter um computador rápido, certo?

Estas questões surgem no contexto de uma dúzia de outros gráficos com vários EAs/indicadores poderem transformar um computador rápido num computador lento (e um comerciante médio utiliza exactamente muitos EAs - por exemplo https://www.mql5.com/ru/forum/267154/page5#comment_8164924 - 82 EAs estão em execução)... Ou mesmo um computador lento pode ficar lento por um curto período de tempo devido a outras circunstâncias (antivírus... outros programas... ou o próprio sistema tomou temporariamente conta de quase todos os recursos).

E então exactamente esse inexplicável fracasso 1 em cada 100 irá acontecer (e pelas leis da natureza ocorre naturalmente no momento mais inoportuno).

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

Assim, a pedido #1530548 ServiceDesk não pode reproduzir o erro https://www.mql5.com/ru/forum/1111/page1628#comment_2702870 mesmo que eu tenha uma reprodução estável mesmo agora (na construção 1881). Com um pouco de reflexão, descobri porquê! A resposta é: porque tenho um computador lento (tablet)

A mesma situação estava em aplicação #1952509 para este problema https://www.mql5.com/ru/forum/1111/page2124#comment_6518537

O ServiceDesk também informou no início que não conseguia reproduzir o erro. Foi preciso um grande esforço para me convencer de que afinal houve um erro. no final:

Equipa de Apoio 2018.02.10 22:35
Parece ter reproduzido o seu problema na sexta-feira, numa máquina fraca com 39 gráficos.
Ficaremos atentos a isso. Solicitará dados adicionais, se necessário. Obrigado.

Isto levanta a questão: será necessário preocupar-se com tais erros? Ou deixá-los viver em paz ... talvez não voltem a aparecer - basta ter um computador rápido, certo?

Estas questões surgem no contexto de uma dúzia de outros gráficos com vários EAs/indicadores poderem transformar um computador rápido num computador lento (e um comerciante médio utiliza exactamente muitos EAs - por exemplo https://www.mql5.com/ru/forum/267154/page5#comment_8164924 - 82 EAs estão em execução)... Ou mesmo um computador lento pode ficar lento por um curto período de tempo devido a outras circunstâncias (antivírus... outros programas... ou o próprio sistema tomou temporariamente conta de quase todos os recursos).

E então exactamente esse inexplicável fracasso 1 em cada 100 ocorrerá (e pelas leis da natureza ocorre naturalmente no momento mais inoportuno).


Não tenho um computador fraco. Mas este erro de abertura do ficheiro também ocorre de tempos a tempos.

 
Vladislav Andruschenko:
Não tenho um computador fraco. Mas este erro na abertura de um ficheiro também ocorre de tempos a tempos.
Tanto mais que não é um utilizador comum, e o seu trabalho é utilizado por muitas, muitas pessoas
1...223222332234223522362237223822392240224122422243224422452246...3184
Novo comentário