Why do some QWidgets create own threads?
Hi,
I am working on a multi-threading program, which has the ability to create dynamically pages for the Tab-Widget.
These pages for the tab-widget are made of a self made page-template class.
In that template I have the whole widgets I need to create that page.
All of them are created on the Heap.
My theory is:
my_programs_core (5 Threads) + main_gui( 1 Thread)
But it is:
my theory(6 Threads) + QLineEdit of mainGUI(2 Threads) + QFileDialog for save and load (2 Threads)..
My question is:
Why do a QLineEdit located on my main-page (not on the pages for the Tab-Widget)
creates 2 Threads?
And in my template-class there are two QFileDialog instances for each page. (Load file / save file)
It means every time I create a new page with my template class I will get 2 Threads without a reason.
Can someone explain me that?
Re: Why do some QWidgets create own threads?
QFileDialog might be using a separate thread for populating QFileSystemModel. QLineEdit shouldn't be using separate threads unless you are using a completer with QFileSystemModel.
Re: Why do some QWidgets create own threads?
Thanks,
you are right
Code:
somewhere in the code:
model = new QFileSystemModel(q);
But QLineEdit creates 2 Threads in my simple case.
Somewhere in the code in its init
Code:
q->setAcceptDrops(true); //here it creates 2 threads
:confused::confused:
Re: Why do some QWidgets create own threads?
Am I the only one where QLineEdit creates threads?
Re: Why do some QWidgets create own threads?
QLineEdit is not using any threads, at least not by itself. Why did you think it was using threads?
Re: Why do some QWidgets create own threads?
donglebob is right. Instantiating QLineEdit creates threads of its own. On my system (Windows 7, Qt 4.6.2) it creates 4 threads! Actually, the threads are created inside QWidget::setAcceptDrops(), because QLineEdit calls this method inside the constructor. After a bit more debugging I've found out that the threads are created by a WinAPI function CoLockObjectExternal
Edit: I've found a way to prevent this behavior. One must call before the widget is shown.