Errors, bugs, questions - page 2707
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
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
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).
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 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
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.
I don't use it. The code to reproduce the problem is attached.
Replace SocketTlsRead with SocketTlsReadAvailable
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.
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.
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?
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.
UPD:
Ilyas's recommendation has been seen.
Yes, without this feature, there is no problem with the connection.
The problem is reading.
Replace SocketTlsRead with SocketTlsReadAvailable
I tried the same replacement with SocketTlsReadAvailable
The behaviour is the same as withSocketTlsRead
UPD:
The same problem exists when using SocketTlsHandshake on a different port.