Errors, bugs, questions - page 2707

New comment
 
Sergey Dzyublik:

Please the developers(@Ilyas) pay attention to the detected bug.
Bug MT5 (build 2377) when selecting appropriate overloaded function for argument of pointer type, the function with type conversion to pointer toparent class instead of base class becomes higher priority.
Also no compile time error when pointer to base class is assigned to pointer to parent class.

Possibly related bug: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
}

Thanks for the message.

Corrected by

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


Remains as is - this code may result from template specialisation (in a part that will not work, but will affect compilation).

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

Yes indeed in your code, on port 80 header is returned, on 443 not.
Revisited your code again, and didn't see SocketTlsHandshake function there.
Your code doesn't do a handshake. This may be the reason.
Although the help for this function says that it is not required if you connect to port 443.

Exactly, that's not my code, but from developers' example (sockets from MQ have some unintuitive features which sometimes get figured out on forum, so I turned to standard example). I tried SocketTlsHandshake - it always returns false in all conditions and has no effect on solving problems. Since certificate data is returned, the handshake goes through. Even the header, judging by its length, comes, but just doesn't return to the MQL code. The error code is too generic and the error itself is questionable. We need an insider's view.
 
Stanislav Korotky:
Exactly, that's not my code, but from the developers' example (sockets from MQ have some unintuitive features, which are figured out sometimes in the forum, so I turned to the standard example). I tried SocketTlsHandshake - it always returns false in all conditions and has no effect on the solution. Since certificate data is returned, the handshake goes through. Even the header, judging by its length, arrives, but just doesn't return to the MQL code. The error code is too generic and the error itself is questionable. We need an insider's view.

No need to use the SocketTlsHandshake function if the connection is initially secure ("https://" or port 443 or 465)

The function is used in special cases/protocols

 
Ilyas:

SocketTlsHandshake does not need to be used if the connection is initially secured ("https://" or port 443 or 465)

The function is used in special cases/protocols

I don't use it. The code to reproduce the problem is attached.

 
Stanislav Korotky:

I don't use it. The code to reproduce the problem is attached.

Replace SocketTlsRead with SocketTlsReadAvailable

 
Ilyas:

Replace SocketTlsRead with SocketTlsReadAvailable

Can you be more specific? In the example documentation it was SocketTlsRead that was used. Why wasn't SocketTlsReadAvailable used there?

When should I use one function and when should I use another?

How to write universal code for blocking a read from a socket, suitable for both protected and unprotected connections - we don't have the SocketReadAvailable function, do we?

PS. Changed the function. Error didn't disappear. Here is the updated code. GetLastError returns 0.

Files:
SocketExample.mq5  4 kb
 

In visual tester, call ofCopyTicksRange function from indicatorterminates with error 4014 (ERR_FUNCTION_NOT_ALLOWED).

The same indicator works fine online on the same instrument. What's the problem? Is this function prohibited in the tester? Didn't find any mention of it in the help.

 
Stanislav Korotky:

In visual tester, call ofCopyTicksRange function from indicatorterminates with error 4014 (ERR_FUNCTION_NOT_ALLOWED).

The same indicator works fine online on the same instrument. What's the problem? Is this function prohibited in the tester? I did not find it in the help.

Testing by real ticks?

 
Stanislav Korotky:
Exactly, that's not my code, but from the developers' example (sockets from MQ have some unintuitive features that sometimes get figured out in the forum, so I turned to the standard example). I tried SocketTlsHandshake - it always returns false in all conditions and has no effect on problem solving. Since the certificate data is returned, the handshake goes through. Even the header, judging by its length, comes, but just doesn't return to the MQL code. The error code is too generic and the error itself is questionable. We need an insider's view.

Yeah, I was surprised too that without SocketTlsHandshake the certificate is returned.
But with the SocketTlsHandshake function, it calls the error.
There's some kind of implicit logic in the behaviour.

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

UPD:
Ilyas's recommendation has been seen.
Yes, without this feature, there is no problem with the connection.
The problem is reading.
 
Ilyas:

Replace SocketTlsRead with SocketTlsReadAvailable

I tried the same replacement with 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);

The behaviour is the same as withSocketTlsRead

UPD:
The same problem exists when using SocketTlsHandshake on a different port.

1...270027012702270327042705270627072708270927102711271227132714...3189
New comment