@dheerendra no issues so far. Will update. Thank you.

Perfect !!!! What a group !!! Thanks very much, this save me a lot work !!!

This is an awesome new feature and now I can use it.

Rick

Hi,

Looks like there's some problem with the PySide 2 implementation. You should check the bug report system to see if it's something known. If not, please consider opening a new report providing your example and as much details as possible about your current setup.

I agree you need to use a state machine for that case. http://doc.qt.io/qt-5/qstatemachine.html probably helps putting down the skeleton already

Please excuse my late reply. I wanted to think about this a bit.

I guess we all agree that the documentation is not wrong. It clearly states that slots are not executed in a separate thread when subclassing QThread. Personally, I also feel like this is not exactly "buried" in the documentation.

The main problem I see is that people that start coming across QThread are getting misleaded very easily by those famous blog posts that try to tell you how to do it, and then not to do it like that, but then again, it's apparently fine too.
I feel like the a paragraph could be added to the documentation which clearly states when subclassing QThread is needed and when not. Basically a: "Only subclass QThread if ....
Which might be followed by a "Things to keep in mind" bullet list which lists the "special properties" or "pitfalls".

At the end it really just boils down to the fact that QThread is not a thread but just a thread wrapper. From my personal experience I feel like this is very different from how other frameworks provide threading.
Of course I understand that renaming QThread is out of the question but I feel like some very generic information paragraph in form of a bullet list might help a lot.

Thanks, I will check!

@Buckwheat Thank you documents link. I will read it and trying to make change in my code. thank you @Buckwheat .

I feel like this is a perfect personification of the "came searching for copper but found gold meme", Sometime in the past I acknowledged that modifying UI elements in a secondary thread caused crashes, I even fixed it, then when I moved my project from computer to computer i must have copied an old file or something, and forgot that that was a no-no. But I digress, not only did this thread solve my problem, it also showed me a way to ditch cURL, and rely solely on QT, as well as circumvent the necessity of the threading in the first place, so thank you all for answering my question and more @Buckwheat / @VRonin /@kshegunov

response is quite different from QImage, so you should start by matching your function prototypes. To that end you should use the Qt5 connect syntax, which is going to throw you a compile-time error for that code, as it justifiably should. I don't understand the rationale between that global variable - response cevap; though, you should explain what prompted you to use it like this.

@VRonin Merci :-)

@jsulm
Yeah, i understand (just forget to start thread). In that example thread->start() was called though.
In the last example deletion of ThreadEx object should be handled by application main loop.

@SGaist I need the slot send_console_log to be called when the signal written in ConsoleStream is emitted. When running the program with a normal while/for loop in the interpreter, the slot will be called becuase at that moment its non blocking. But the moment I add time.sleep into a loop, slots will only be called at the end when all the blocking is over. Thank you for looking into this.

@mrjj Cheers, that worked for me :)

@BjornW said in Signal and slot to synchronize variable between qthread:

I would separate the objects into two types. One type that is the "master" object and other objects which interact with it.

That's the correct thinking, I consider this whole question to be a design issue. The problem I see is that a dependency is introduced between two QObjects that are in different threads, that is very unnatural to begin with - the two objects shouldn't depend on one another implicitly; it's no mistake that a QObject instance can't have a parent that's living in another thread. In my mind either the dependency should be declared explicitly (e.g. manually synchronizing the objects across the threads in some fashion) or it shouldn't exist at all.

@J.Hilk

Thanks, I was checking wasCanceled() in several places but not just before applying the new value. I was rather sceptical that it would work, but it did.

Still, I would have liked to have learned a better scheme for handling the progress.

Never mind,

I had code in my the constructor of the to be threaded class, that caused the conflict...

connect(&modbusThread, &QThread::started, modbusDevice, &Modbus::setupClass);

fixed the issue.

Ok, thanks, I think I have all information I need now.

Frankly, I forgot about it.

Then it also depends also on what tools fits best your needs. There's no silver bullet that will cover everything you need.

Also limiting yourself to only one language is not a good idea in the long run. There are good and bad things in every language thus knowing more than one allows to have a better grasp at what can be done, how easy/hard the maintenance would be etc.

That crashes because you have to put every worker-> inside a if(worker) to make sure you are not operatng on a null pointer.

Can you tell me the exact sequence of operations that lead to the problem?

@Ahti
Please read how C++ manages objects' lifetimes.

For the FAQ:
https://isocpp.org/wiki/faq/dtors#dont-call-dtor-on-obj-allocd-via-new

Спасибо за объяснение, я Вас понял, я добавил moveToThread() перед connect() мне это не помогло, наверное, делаю что то не так. Я попробовал вариант, когда наследуется класс от QThread и в его методе run выполняется нужная функция. В этом случае потоки выполняются параллельно, но мне этот вариант с точки зрения ООП не очень...
Буду благодарен за советы!

The export (or lack thereof) definitely was the problem. Once I got in this morning and cleaned up by code a little and rebuilt everything the export is now working fine. I must have had an old build of something that wasn't getting cleaned.

Anyway thanks for the help!

Hi,

What about doing the subscription related stuff in your proxy ? Basically two methods:

FeedProxy::subscribe(YouCoolClass *) FeedProxy::unsubscribe(YouCoolClass *)

No need for any special detection and you know exactly where things are happening.

I had to add Q_OBJECT and also delete my debug folder once, to get rid of a few link errors.

Also got rid of the QThread subclassing, it is way easier to create a worker class and connect it through signals. There is really a lot of outdated example code out there.

Thanks for your help!

@beecksche said:

The advatage of a QScopedPointer is that you don't have to care about the destruction of the object, right?

Yes. It's a thin wrapper around the raw pointer and will delete the held reference when it goes out of scope. The idea is to use the stack based QScopedPointer object to manage the heap-allocated object it's referencing.

Kind regards.

Thanks for your reply and help!

It is working now and the reason was the listen() was in the wrong position and you need an additional Signal/Slot connection from main program to the network extension as following:

the main program gets changed like this:

wifi= new WirelessNet(0); QThread *thread = new QThread; wifi->moveToThread(thread); connect(thread,SIGNAL(started()), wifi,SLOT(initWifi())); thread->start();

the constructor of WirelessNet is now empty, therefore it gets a new public slot function:

void WirelessNet::initWifi() { listen(QHostAddress::Any, 5220); }

And that's the trick.

If one is creating a WirelessNet-Instance, starts listenting inside the constructor but first then uses the movetoThread(), the connection is lost.

Concluding in one sentence: First move to the right thread and afterwards start listening

Thanks for your help. Let me tell you I hate the official Qt-""Tutorials""

@QtExchange
Forgot to link those two, which are very important to understand before working with threads:
QObjects' thread affinity: http://doc.qt.io/qt-5/qobject.html#thread-affinity
Queued connections accros threads: http://doc.qt.io/qt-5/threads-qobject.html#signals-and-slots-across-threads

Hi and welcome to devnet,

Are you also new to coding ? If so, then don't start with threads, that's a pretty complex subject that you should take on later after getting the basics correctly.

Also, for what you described there's no need for threads. Qt's asynchronous nature already provide what's needed.

Start with Qt's documentation. It also contains the Threading Basics

On a side note, it's Qt, QT stands for Apple QuickTime which you might also be interested in.

@slilly said:

Can QTimer be called from a normal C++ main and not a QThread or a main using a QCoreApplication?

No. If you want to use QTimer, then you need QCoreApplication::exec() or QThread::exec().

@zzaj
No problem. Good luck with your project!!

Code would help.
And do you see any error messages when your app crashes? Did you try to debug?

@reezeus said:

Is it a good practice to use QThreadPool even if I have only one thread?

I've never used QThreadPool but I can imagine that it eases scaling if you do so... The day you want to increase the number of threads, simply have a bigger pool. On the other hand if you know that one thread is what you need and will continue to need, QThread seems more reasonable IMHO.

I guess you are right. I will work on this without the Threads. Thank you for your help!

@Catherine-Olsen
Could you mark it as such? The topic tools button is on the bottom and when you click it select "Mark as solved".

@Lazar-Urosevic Yes, you can have two QVideoWidgets at the same time. Why should one of them block? And why not just try it?