OK. I found it. I was being dumb! I have two flavors of Progress Dialogs. One is inside an App, and the other is standalone, meant to be called form a script. I was looking at the one in the App when I should have been looking at the other one. The standalone one doesn't have have a cancel slot.
Like i said, i think you can built your own class by inherit from QModbusDevice to have a synchronous API. The QSerialBus module is marked as technical preview in Qt 5.6, maybe they add some new functions in future releases similar to QTcpSocket like waitForConnected etc.
I tried to catch all possible signals but I didn't get any of them. I think it is because of the way Qt applications are run on Android. Because on Android is run a Java application which runs my app as a library.
Assuming this is true, then indeed, you'll need to write a bit of java and only if the Java runtime allows interception of the signals. I don't know if it's worth it, but it shouldn't be too hard.
@Mark81 Sorry I have misled you, I was confusing the timeout on the wait...() functions with the asynchronous signals. You do not want the wait...() functions in the GUI thread as they block.
The first thing to note is that normal TCP/IP will retry 12 times to send a data segment taking up to 9 minutes before it causes an error.
I think you have two choices in the normal TCP/IP framework.
If you are sending data and expecting a reply, you can start a single shot timer that is cancelled if the reply is received but causes your communications failed code to run when it times out.
If you are just waiting for data then you will get no notification of errors as TCP/IP will wait forever on a disconnected circuit. So in this case you must have your server send you periodic "heartbeat" data to confirm its reachability.
@errolflynn You should write self.button1.clicked.connect(ft_handler) - this will register the function ft_handler as a slot for the clicked signal. On http://doc.qt.io/qt-5/qabstractbutton.html you see that the signature of that signal is void clicked(bool checked). In other words, when the signal is activated, your handler is called as ft_handler(checked) where checked is either True or False. Per the signature of the clicked signal, this is the only information you will get out of the signal.
If you want to pass additional parameters, you indeed will need to create a separate function that encodes those extra parameters and passes them to the handler. In Python it makes a lot of sense to use a lambda for it, for instance:
self.button1.clicked.connect(lambda checked: fct_handler(par1, par2, par3, checked))
When I go to the forum to solve a problem it is because I could not find anything on the web, but in this case was too simple theme, perhaps only experiencing what he had resolved because it is too simple to implement signals and slots between the application and the dll
To end the post: to implement the slot in the plug receiving a signal from the application, add the virtual interface slot
virtual void disparador(QString texto) = 0;
Are you sure the signal isn't getting emitted or is it a getting emitted but the sendmail object isn't picking it up? My guess is your send mail object is doing something (locked up and never going back to the event loop). So it is never receiving that second message since it never gets back to the event loop.
Don't know for sure without seeing the code for it, but just something I've noticed in thread programming with Qt.
You could gdb to break into the application and see what your thread is doing. If it isn't in processEvents() that is probably the issue.
Oh and one more thing, you can easily test the emitter by create a fake sendmail object with that same slot, then just have it write to the console when it sees that signal. That way you know if is doing nothing but writing to the console and exiting the slot so there won't be any hang ups. My guess is it will work and that your problem lies in the sendmail object.
As it looks to me the installation of Qt 5.2.1 is broken. If possible you should also install the newest version of Qt libs IMHO.
However, from personal experience it might be also worthwhile to update your Ubuntu. I am operating a server with Ubuntu 12.04 and had quite a bit of trouble in connection Qt 5 there. Luckily the admin there, "some" version (5.0 or 5.1) to work at least moderately.
On Ubuntu 14.04 on my desktop everything worked like a charm.
Finally I like to state that I am developing on Windows. Therefore, my Linux knowledge is limited as well.