On 20.07.10 12:36:48, Jason Ferrara wrote: > I have a need to update a QProgressBar while a slider is begin dragged, > without processing user events. > . > I tried calling QProgressBar.repaint(), as shown in the sample code below. > This works fine for linux/X11 (and osx/X11), but for osx/aqua I never see the > progress bar change. It seems that repaint() under osx has no effect. I'm > guessing that it causes drawing to occur to the off screen buffer, but never > copies that to the main screen. > > I tried calling QApplication.processEvents(QEventLoop.ExcludeUserInputEvents) > instead of QProgressBar.update(). That makes the progress bar update > correctly, but I end up with funny slider movements where it jiggles back and > forth a bit instead of exactly tracking the mouse, and weird focus issues > where the next few mouse clicks after the last call to > QApplication.processEvents(QEventLoop.ExcludeUserInputEvents) get sent to the > wrong widget. > > In case anyone is wondering why I need to do this... > > My app does data visualization, and I have a slider that makes some > adjustments to my display widget. Most of the time the adjustment occurs near > instantaneously, so that the user sees the display update in real time as > they drag the slider. But occasionally, depending on the nature of the data, > the adjustment to the display widget can take up to 10 seconds. So when the > adjustment takes a long time I need some way to inform the user that the app > is processing their request (and hasn't hung) and give an estimate of how > long its going to take for the screen to update. If I allow normal event > handling while the adjustment to the widget is begin made (by calling > processEvents() or running the adjustment in a separate thread) then the > adjustment of the display widget would lag way behind the slider movement, > and the user would have the ability to trigger some other operation on the > display widget during the adjustment, which would lead to corruption of data > in the widget. > > Does anyone have any suggestions on how to get the same progress bar update > behavior I see under X11 to occur under osx/aqua?
If QEventLoop.ExcludeUserInputEvents doesn't do what you want you'll either have to live without progressbar-updating or try to convince Nokia that there's a bug in their code that triggers the strange effects you're seeing. Andreas -- Your boss is a few sandwiches short of a picnic. _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt