Erros, bugs, perguntas - página 2707

Novo comentário
 
Sergey Dzyublik:

Por favor, os programadores(@Ilyas) prestem atenção ao bug detectado.
Bug MT5 (build 2377) ao seleccionar a função sobrecarregada apropriada para argumento do tipo ponteiro, a função com conversão do tipo para a classepai em vez da classe base torna-se maior prioridade.
Também não há erro de tempo de compilação quando o ponteiro para a classe base é atribuído ao ponteiro para a classe pai.

Possivelmente um bug relacionado:https://www.mql5.com/ru/forum/1111/page2682#comment_15591437

class A{};
class B : public A{};
class C : public B{};


struct T{
   static void test(A*){
      printf("A*");
   }
   static void test(C*){
      printf("C*");
   }
};

struct TT{
   static void test(B*){
      printf("B*");
   }
};

void OnStart(){
   B b;
   T::test(&b);            // Runtime Error: Incorrect casting of pointers.  Expected result: printf("A*");
   
   A a;
   TT::test(&a);           // Runtime Error: Incorrect casting of pointers.  Expected result: Compilation Error
   B* ptr = &a;            // Runtime Error: Incorrect casting of pointers.  Expected result: Compilation Error
}

Obrigado pela mensagem.

Corrigido por

Runtime Error: Incorrect casting of pointers.  Expected result: printf("A*");


Permanece como está - este código pode resultar da especialização do modelo (numa parte que não funcionará, mas que afectará a compilação).

Runtime Error: Incorrect casting of pointers.  Expected result: Compilation Error
Runtime Error: Incorrect casting of pointers.  Expected result: Compilation Error
 
Roman:

Sim, de facto no seu código, na porta 80 cabeçalho é devolvido, na 443 não.
Revisitou o seu código novamente, e não viu aí a função SocketTlsHandshake.
O seu código não faz um aperto de mão. Esta pode ser a razão.
Embora a ajuda para esta função diga que não é necessária se se ligar à porta 443.

Exactamente, esse código não é meu, mas do exemplo dos programadores (as tomadas da MQ têm algumas características pouco intuitivas que por vezes são descobertas no fórum, por isso virei-me para o exemplo padrão). Tentei SocketTlsHandshake - regressa sempre falso em todas as condições e não tem qualquer efeito na resolução de problemas. Uma vez que os dados do certificado são devolvidos, o aperto de mão passa. Mesmo o cabeçalho, a julgar pelo seu comprimento, vem, mas simplesmente não regressa ao código MQL. O código de erro é demasiado genérico e o próprio erro é questionável. Precisamos da opinião de um informador.
 
Stanislav Korotky:
Exactamente, este não é o meu código, mas a partir do exemplo dos programadores (as tomadas da MQ têm algumas características pouco intuitivas, que por vezes são descobertas no fórum, por isso recorri ao exemplo padrão). Tentei o SocketTlsHandshake - regressa sempre falso em todas as condições e não tem qualquer efeito sobre a solução. Uma vez que os dados do certificado são devolvidos, o aperto de mão passa. Mesmo o cabeçalho, a julgar pelo seu comprimento, chega, mas simplesmente não regressa ao código MQL. O código de erro é demasiado genérico e o próprio erro é questionável. Precisamos da opinião de um informador.

Não há necessidade de utilizar a função SocketTlsHandshake se a ligação for inicialmente segura ("https://" ou porta 443 ou 465)

A função é utilizada em casos/protocolos especiais

 
Ilyas:

SocketTlsHandshake não precisa de ser utilizado se a ligação for inicialmente assegurada ("https://" ou porta 443 ou 465)

A função é utilizada em casos/protocolos especiais

Não o uso. O código para reproduzir o problema está anexado.

 
Stanislav Korotky:

Não o uso. O código para reproduzir o problema está anexado.

Substituir SocketTlsLeitura por SocketTlsLeituraDisponível

 
Ilyas:

Substituir SocketTlsLeitura por SocketTlsLeituraDisponível

Pode ser mais específico? No exemplo da documentação foi utilizada a SocketTlsRead. Porque é que a SocketTlsReadAadisponível não foi aí utilizada?

Quando devo usar uma função e quando devo usar outra?

Como escrever código universal para bloquear uma leitura a partir de uma tomada, adequado tanto para ligações protegidas como não protegidas - não temos a função SocketReadAvailable, pois não?

PS. Alterou a função. O erro não desapareceu. Aqui está o código actualizado. GetLastError retorna 0.

Arquivos anexados:
SocketExample.mq5  4 kb
 

No testador visual, a chamada da funçãoCopyTicksRange do indicadortermina com o erro 4014 (ERR_FUNCTION_NOT_ALLOWED).

O mesmo indicador funciona bem online no mesmo instrumento. Qual é o problema? Esta função é proibida no testador? Não encontrou qualquer menção na ajuda.

 
Stanislav Korotky:

No testador visual, a chamada da funçãoCopyTicksRange do indicadortermina com o erro 4014 (ERR_FUNCTION_NOT_ALLOWED).

O mesmo indicador funciona bem online no mesmo instrumento. Qual é o problema? Esta função é proibida no testador? Não o encontrei na ajuda.

Teste por carrapatos reais?

 
Stanislav Korotky:
Exactamente, este não é o meu código, mas a partir do exemplo dos programadores (as tomadas da MQ têm algumas características pouco intuitivas que por vezes são descobertas no fórum, por isso recorri ao exemplo padrão). Tentei o SocketTlsHandshake - regressa sempre falso em todas as condições e não tem qualquer efeito na resolução de problemas. Uma vez que os dados do certificado são devolvidos, o aperto de mão passa. Mesmo o cabeçalho, a julgar pelo seu comprimento, vem, mas simplesmente não regressa ao código MQL. O código de erro é demasiado genérico e o próprio erro é questionável. Precisamos da opinião de um informador.

Sim, também fiquei surpreendido que sem o SocketTlsHandshake o certificado seja devolvido.
Mas com a função SocketTlsHandshake, chama o erro.
Há algum tipo de lógica implícita no comportamento.

if(SocketConnect(socket, Address, Port, 5000) && SocketTlsHandshake(socket, Address))
Can't connect to echo.websocket.org:443, error 5274

UPD:
A recomendação de Ilyas já foi vista.
Sim, sem esta característica, não há problema com a ligação.
O problema é a leitura.
 
Ilyas:

Substituir SocketTlsLeitura por SocketTlsLeituraDisponível

Experimentei o mesmo substituto com SocketTlsReadAvailable

int rsp_len; 

if(ExtTLS)
   rsp_len = SocketTlsReadAvailable(socket, rsp, len); 
   //rsp_len = SocketTlsRead(socket, rsp, len);
else
   rsp_len = SocketRead(socket, rsp, len, timeout);

O comportamento é o mesmo que comSocketTlsRead

UPD:
O mesmo problema existe quando se usa SocketTlsHandshake num porto diferente.

1...270027012702270327042705270627072708270927102711271227132714...3184
Novo comentário
Razão: