thank you for the direction.

@VRonin
you knew what bro :D ^^ when the model gets data there's a values higher than the max of the progressbar that's why it takes the size of other columns ... when i set higher progressBarOption.maximum = 100;
problem solved
Thank you so much
without you i coudn't find it even if it was that easy

In my programm, I got

QThread: Destroyed while thread is still running

when I was using operationDone, changing into finished relolved this problem

@sgaist said in Building a "complex" progress widget:

Don't try to steal anything. Use signals and slots to communicate from your secondary threads back to your main thread.

Yes, but as far as I can tell the main thread is "working" (or user has took control over it) as it spawned the secondary threads and is waiting for them to finish processing before moving on.

Edit
Ok so I've now run QMetaObject::invokeMethod(this,={callToLongFunction},Qt::QueuedConnection);
This appear to work, however any loop that was being

#pragma omp parallel for
for (){}

No longer threads... so qt somehow manages to break the omp multithreading ? -- well standalone teste indicates that no... all works there but my app stopped threading... sweet.

Ok I'm a nub, its official! Everything works. It threads & runs job in qt internal event loop thus I don't have any issues. Wow. Ok I need to learn more on qt threading event loop :D I need to fork one for myself and have it process all my work stuff now :- ))

EDIT...

Ok seems like I did a full loop. I went from processing in user thread to processing in qt event loop - fine - but pragma still wont update the widget at the correct time... sigh. Since now we are in event loop, the processing of function is more important than processing of omp thread update signal... I need some kind of priority attached to signal to tell qt that hey... I know u have ur loop but process this signal now.
Right now with Qt::DirectConnection while trying to update val/etc I get this >

###### WARNING: QWidget::repaint: Recursive repaint detected ((null):0, (null)) ###### ###### WARNING: QBackingStore::endPaint() called with active painter on backingstore paint device ((null):0, (null)) ######

And aparently by putting this inside omp seems to "work"...

if (omp_get_thread_num() == 0) { qApp->processEvents(); } ```... ahhhh multithreading <3

you are right, now it works fine.

I did the test and appearantly it's the painting which is very expensive... with no slot connected, the program takes 1,5 seconds to complete the task. There is a very similar issue reported at https://bugreports.qt.io/browse/QTBUG-49655.

But generally ProgressBars are consuming especially when we update it that often (>365000 times) while there is no significant change at each iteration. So I simply update the QProgressBar less often and the results are good (~1s) and the progression still smooth. PSB :

class ParseFileAsync(QtCore.QThread): match = QtCore.pyqtSignal(str) PBupdate = QtCore.pyqtSignal(int) PBMax = QtCore.pyqtSignal(int) def run(self): with open("test_long.log", "r") as fichier: fileLines = fichier.readlines() self.lineNumber = len(fileLines) self.PBMax.emit(self.lineNumber) if (self.lineNumber < 30): self.parseFile(fileLines, False) else: self.parseFile(fileLines, True) def parseFile(self, fileLines, isBig): cpt = 0 if(isBig): for line in fileLines: cpt+=1 if(cpt % (int(self.lineNumber/30)) == 0): self.PBupdate.emit(cpt) for element in liste: if element in line: self.match.emit(line) self.PBupdate.emit(self.lineNumber) #To avoid QProgressBar stopping at 99% else: for line in fileLines: cpt+=1 self.PBupdate.emit(cpt) for element in liste: if element in line: self.match.emit(line)

Hi,
Thank you so much. I did it.

Thank you for your answers, I will look into both QThread and QtConcurrent.

@hamov

well digging around, I also found
m_list->viewport()->repaint();

which works for WidgetList. Did not test with model/view yet.

I think it is by design as it does redraw when data changes but we are not alone finding
it strange working if one google it

Hi,

If you can reproduce that with a minimal compilable example then it's likely to be a bug.

What exactly do you mean with blinking?
If you have set a min and a max value, there is no blinking animation. It just shows the currently set value.
You may need to look at documentation again: http://doc.qt.io/qt-4.8/qprogressbar.html

You can subclass QProgressBar and reimplement the text function to return what you want.

I have it working:

QString style = "QProgressBar::chunk {background: hsva(%1, 255, 255, 70%);}"; ui->progressBar->setStyleSheet(style.arg(data.section(' ', 2, 2).toInt(&ok, 10)));

Thanks

Thanks :)

QSS don't support this? :(