Errores, fallos, preguntas - página 2707

Nuevo comentario
 
Sergey Dzyublik:

Por favor, los desarrolladores(@Ilyas) presten atención al error detectado.
Bug MT5 (build 2377) al seleccionar la función sobrecargada adecuada para un argumento de tipo puntero, la función con conversión de tipo a puntero a la clasepadre en lugar de a la clase base tiene mayor prioridad.
Tampoco hay error de compilación cuando el puntero a la clase base se asigna al puntero a la clase padre.

Error posiblemente 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
}

Gracias por el mensaje.

Corregido por

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


Se mantiene como está - este código puede resultar de la especialización de la plantilla (en una parte que no funcionará, pero que afectará a la compilación).

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

Sí, efectivamente en tu código, en el puerto 80 se devuelve la cabecera, en el 443 no.
Volví a revisar tu código y no vi la función SocketTlsHandshake allí.
Tu código no hace un apretón de manos. Esta puede ser la razón.
Aunque la ayuda de esta función dice que no es necesaria si se conecta al puerto 443.

Exactamente, ese no es mi código, sino del ejemplo de los desarrolladores (los sockets de MQ tienen algunas características poco intuitivas que a veces se descubren en el foro, por lo que recurrí al ejemplo estándar). Probé SocketTlsHandshake - siempre devuelve false en todas las condiciones y no tiene ningún efecto en la resolución de problemas. Dado que se devuelven los datos del certificado, el apretón de manos se lleva a cabo. Incluso la cabecera, a juzgar por su longitud, llega pero no vuelve al código MQL. El código de error es demasiado genérico y el propio error es cuestionable. Necesitamos una visión interna.
 
Stanislav Korotky:
Exactamente, ese no es mi código, sino el del ejemplo de los desarrolladores (los sockets de MQ tienen algunas características poco intuitivas, que se averiguan a veces en el foro, así que recurrí al ejemplo estándar). SocketTlsHandshake lo he probado - siempre devuelve false en todas las condiciones y no tiene ningún efecto en la resolución del problema. Dado que se devuelven los datos del certificado, el apretón de manos se lleva a cabo. Incluso la cabecera, a juzgar por su longitud, llega, pero no vuelve al código MQL. El código de error es demasiado genérico y el propio error es cuestionable. Necesitamos una visión interna.

No es necesario utilizar la función SocketTlsHandshake si la conexión es inicialmente segura ("https://" o puerto 443 o 465)

La función se utiliza en casos/protocolos especiales

 
Ilyas:

No es necesario utilizar SocketTlsHandshake si la conexión es inicialmente segura ("https://" o el puerto 443 o 465)

La función se utiliza en casos/protocolos especiales

No lo uso. Se adjunta el código para reproducir el problema.

 
Stanislav Korotky:

No lo uso. Se adjunta el código para reproducir el problema.

Sustituir SocketTlsRead por SocketTlsReadAvailable

 
Ilyas:

Sustituir SocketTlsRead por SocketTlsReadAvailable

¿Puede ser más específico? En la documentación del ejemplo se utilizaba SocketTlsRead. ¿Por qué no se usó SocketTlsReadAvailable allí?

¿Cuándo debo utilizar una función y cuándo otra?

Cómo escribir un código universal para bloquear una lectura de un socket, adecuado tanto para conexiones protegidas como no protegidas - no tenemos la función SocketReadAvailable, ¿verdad?

PS. Cambió la función. El error no ha desaparecido. Aquí está el código actualizado. GetLastError devuelve 0.

Archivos adjuntos:
SocketExample.mq5  4 kb
 

En el probador visual, la llamada a la funciónCopyTicksRange del indicadortermina con el error 4014 (ERR_FUNCTION_NOT_ALLOWED).

El mismo indicador funciona bien en línea en el mismo instrumento. ¿Cuál es el problema? ¿Está prohibida esta función en el probador? No he encontrado ninguna mención al respecto en la ayuda.

 
Stanislav Korotky:

En el probador visual, la llamada a la funciónCopyTicksRange del indicadortermina con el error 4014 (ERR_FUNCTION_NOT_ALLOWED).

El mismo indicador funciona bien en línea en el mismo instrumento. ¿Cuál es el problema? ¿Está prohibida esta función en el probador? No lo encontré en la ayuda.

¿Pruebas con garrapatas reales?

 
Stanislav Korotky:
Exactamente, ese no es mi código, sino el del ejemplo de los desarrolladores (los sockets de MQ tienen algunas características poco intuitivas que a veces se resuelven en el foro, así que recurrí al ejemplo estándar). Probé con SocketTlsHandshake - siempre devuelve false en todas las condiciones y no tiene efecto en la resolución del problema. Dado que se devuelven los datos del certificado, el apretón de manos se lleva a cabo. Incluso la cabecera, a juzgar por su longitud, viene, pero simplemente no vuelve al código MQL. El código de error es demasiado genérico y el propio error es cuestionable. Necesitamos una visión interna.

Sí, a mí también me ha sorprendido que sin SocketTlsHandshake se devuelva el certificado.
Pero con la función SocketTlsHandshake, llama al error.
Hay una especie de lógica implícita en el comportamiento.

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

UPD:
Se ha visto la recomendación de Ilyas.
Sí, sin esta característica, no hay problema con la conexión.
El problema es la lectura.
 
Ilyas:

Sustituir SocketTlsRead por SocketTlsReadAvailable

He intentado el mismo reemplazo con 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);

El comportamiento es el mismo que conSocketTlsRead

UPD:
El mismo problema existe cuando se utiliza SocketTlsHandshake en un puerto diferente.

1...270027012702270327042705270627072708270927102711271227132714...3188
Nuevo comentario