Problem emitting signal from a static function

[Valheru]

Does the receiver reimplement QObject::customEvent() to catch the custom event? Is the event type larger or equal to QEvent::User?

No, I hadn't set it up yet but I was busy doing so. I thought I would just fire off the event and made sure I was on the right track. Didn't expect it to stop the decoder working...
I am using QEvent::User as the event type though.

[Valheru]

No, I hadn't set it up yet but I was busy doing so. I thought I would just fire off the event and made sure I was on the right track. Didn't expect it to stop the decoder working...
I am using QEvent::User as the event type though.

Ok, that sucks. When the event is caught in the main GUI thread, I then access the other thread using a public function to get the current progress. however, this causes the program to crash immediately. Is it forbidden to access QThreads this way? In Java I can simply use a public function with no ill effects between threads - is that possible with QThreads? Or should I set up some round-robbin thread/slot implementation?

[marcel]

Does that function do any other stuff?

Regards

[jpn]

Why not bundle the progress into the QEvent object?

[Valheru]

Why not bundle the progress into the QEvent object?

I don't know how The docs don't mention it either as far as I can see, unless you mean by subclassing it?

[marcel]

Yes, of course you have to create a custom event.
Don't forget to give it an id greater or equal that QEvent::User.

You can add some extra members to your subclass to hold the progress data and whatever you may need.

[jpn]

See the attached example.

[Michiel]

I'm not sure if a solution has been found yet, but maybe you could simply keep a single global object to which to connect signals/slots. This could be a global variable or a singleton object or something similar. You can control that object from your static function.

[wysota]

I think that was already suggested in the other thread. From what I've read here, the solution with posting a custom event I find most appealing as you don't need a "sender" object for that.

Using a global object should work but at the same time violates some rules of good design, while the solution using events directly seems to be ok.

[high_flyer]

Was my explanation that bad?

Probably not, but since I am doing it "along side" my work, my concentration can span so much

In Java I can simply use a public function with no ill effects between threads - is that possible with QThreads? Or should I set up some round-robbin thread/slot implementation?

Well, in C++ you have to make sure the function is thread safe - that means - that there is no situation where two threads are trying to access the same reasorce at the same time.
You should use mutex or semaphores to protect the mutual excluded code.

I too vote for the custom event solution, its the "cleanest".

[wysota]

In Java you have to do the synchronisation as well of course... It's not as simple as calling any function doing anything you want anywhere you want.

[Valheru]

Sorry I didn't update this thread sooner. I did indeed solve it by subclassing QCustomEvent. In the end the solution was simple to implement, and works very well. Thank you all for your help and patience.

/edit : the crash was being caused by accessing a function running in another thread directly. It was solved by bundling the data in the subclassed QCustomEvent as suggested.