Need Qt SerialPort class example using signals and slots WITHIN A THREAD

[wysota]

Yes it is. Please do not try to view this application in terms of something running on a machine where the user can also surf the Web and check email.

And how is that related to anything we've been discussing about? I don't care where the application runs. I care that a single thread doesn't have any problems in reading data from multiple sockets/ports.

That is very poor design and not allowed in a scientific environment were loss of a single data point scraps the entire test run.

What is poor design and how does having another thread prevent loss of some data that would otherwise magically be lost? Data is not lost if you read it 10ms later or 20ms later or even 2 seconds later. It's still there. What matters is that you read data fast enough to prevent cluttering the input buffer. And even that is nothing wrong if you are using TCP as the protocol itself is designed to prevent any data loss. Your serial port doesn't have that safety mechanism and thus you need to pay attention to read the data fast enough to not overrun the input buffer for the port. But it totally doesn't matter which thread performs the read.

It is a design requirement. Do not confuse this with some application on a machine which has any other purpose or ability in life.

Strange. Somehow your flaws are "by design" (yeah yeah, it's a feature, not a bug) and something you consider a "flaw" in others' thinking is "unserious school project". Be serious. Any unresponsive system is badly designed. Period.

I'm not trolling or claiming to have all of the answers. I came in asking if there was unit test code proving this works. I got a bunch of responses which sounded like a Bing commercial.

Yes, you are trolling. Just read your posts.

a point you have repeatedly failed to recognize.

So... QPushButton is also badly designed because it also has a disabled copy constructor? What about QSignalSpy itself? It also has a disabled copy constructor. So does every QObject-derived class. And so does QtSerialPort which is a sign of good design on behalf of its author.

Please don't view this as a user application. This is a single purpose system running in an environment were no data point can be lost.

I'm sorry but as a user of any user application I would not like to have any of my data lost too. And as a programmer of such applications I wouldn't want to have any data lost. Your system is by no means special.

Hence the wish to test with the signal tool.

If you test with the signal tool, the signal will be emitted because the connection from the tool will make its emitter emit it. I think you fail to understand what I meant. Read the docs for QObject::receivers() to see what I meant and how does QSignalSpy influence it.

Projects which get released for use with Qt.

No. My projects never loose any signals, they don't loose any "data points" nor anything like that. They often use multithreading and classes from them are often thread-safe. So please talk about your projects, not about others'.

This message thread can now end.

Thank you, your Grace, for giving us your permission

>____< I used the code you gave me. "I" did not do that. Anyway, thank you.

You subclassed QThread. I didn't.