@Joe-von-Habsburg said in Elided settings limit error: any solution here? due to settings limit So did you check the settings for such a limit?

@Joe-von-Habsburg Ah ha! One of us should have mentioned this when you said about sender packet size :(

Hi. Thank you for the explanation. @Pl45m4 said in MT4 Manager API on QT: Since the MT4 API is probably incompatible with QTcpSocket by default and you probably need to use the Manager's connect function to make everything that is going on in the background work properly, I don't see why you need to use the Qt socket classes, assuming this MT4 Manager has its own internal socket stuff?! I could be wrong, though. Yes this is correct. The only thing is that, when i use the MT4 Manager to connect to the server, it always returns "no connection" error, which means, the MT4 Manager can't establish connection to the server, of which the server is online and i have run the C++ program with the same server credentials.

@Joe-von-Habsburg said in Take message only 1 port by UDP socket receive: How can I ignore ? Look at the QHostAddress and don't process it - there is no other chance except you add some filtering on OS level but Qt can't do anything against it.

@JonB thank you so much

Hi, @calmstack said in QtNetwork: incomingConnection not triggered: @jsulm Isn't it what the official documentation recommends ? No, it's one usage example. You have the same example without threads.

@jsulm Thanks a lot

@sierdzio i think so, thank you so much !

@silau It looks good but ldd doesn't always report exactly what is actually happening when you run your exe. It's a good start though. If you really wanted to trace it further you would have to ldd on each of those libs to see what they link. One of them could be using the 5.6 or whatever other version you may have. That being said I find that to be a bit unlikely though. When I get a little bit of time later today I will run your code using Arch linux and 5.11 and see what happens. That will help determine if maybe it's a bug in Qt (which I highly doubt for something that big). If it works for me the next steps for you would be to run it in the debugger and step through the working 5.6 one during socket connections and then the broken 5.11 one and see what is different. Another option is take it down to the simplest form and just use the chat example or something from Qt and see if it works with 5.11 and then try to see what is different. I'll let you know what I find out on my linux/Qt 5.11 in a bit. Edit: Didn't get a chance today, was really busy. I will run a quick test tomorrow some time though.

@juanki sí, de hecho al final encontre que mi error era porque la IP la tenia que mandar dentro de un método de la librería, igual gracias por tu post :)

Adding the QObject constructor to my class's constructor and adding the pointer-to-member syntax suggested by Kshegunov fixed the issue. Thanks guys and good day.

@jsulm thanks for you reply! it is work! thanks again!

Don't get this the wrong way, but are you coming from Java? I'm asking because this: QHostAddress().AnyIPv4 Doesn't make any sense in C++. What you probably want is to use the scope operator - :: to access one of the enum values. As for the error, please provide the full implementation of your TCP server and mention if you use threading, if so how. Also as mentioned by @koahnig new QTcpSocket(new QObject()); This leaks 2 objects one socket and one generic QObject. You need to provide a valid pointer from the object tree to make use of the automatic deletion Qt supplies for child objects.

It's a bug in Qt. Appears everytime. Even if disable IPv6 stack.

I currently have a very similar problem. I'm implementing a send mail client which should gracefully fall back to an unencrypted connection if encryption fails (and the user has decided to go ahead anyway). For that purpose I've connected to the QAbstractSocket::error() signal. While I do get the signal it's ultimately moot since the code in question (QSslSocketBackendPrivate::startHandshake() in qsslsocket_openssl.cpp) immediately closes the socket by calling QSslSocket::abort() after emitting the signal. Because of that calling QSslSocket::ignoreSslErrors() is never an option. I currently have no workaround in place. Maybe the only solution is to connect to the disconnected() signal and then check whether the connection was closed because of a handshake error. If it was, then open a new unencrypted socket/connection. I'm open to suggestions, though... :-)

@VRonin Server is on a different machine in the LAN and the software is not from me. I only implement the client side.