Erros, bugs, perguntas - página 2239
![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
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?
Digo-lhe já a resposta: estas chamadas serão inválidas
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.
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.
É 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.
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...
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
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?
Além disso, gostaria de saber que funções poderiam potencialmente causar este erro no indicador?
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).
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.
Não tenho um computador fraco. Mas este erro na abertura de um ficheiro também ocorre de tempos a tempos.