Am 31.03.2014 um 12:45 schrieb "william.croc...@analog.com"
<william.croc...@analog.com>:
> On 03/31/2014 03:24 AM, Till Oliver Knoll wrote:
>> Am 30.03.2014 um 22:31 schrieb Brad Pepers<bpep...@me.com>:
>>
>>> ...
>>>
>>> Any hints on where to look for this or maybe some other way to code this to
>>> avoid the problem?
>>
>> I don't know where those "extra paint events" come from (or why),
>> but the most obvious thing for me would be to set a (conditional?) breakpoint
>> in your paint event handler and see from where those calls are triggered, and
> under what condition.
Under the condition that it only breaks when one of the "extra paint events" is
handled. I placed a question mark there because I don't know how you would
differentiate between a "legimitate" and an "extra" paint event, maybe with a
"debug counter variable", or only break when you get a full graphicview
update...
>
> I know from experience that that does not help.
> I'm pretty sure the back trace from paintEvent()
> will just lead to the main event loop, not the
> cause.
Yes, you're absolutely right: we already know where the paint event comes from,
and why ("because someone called update()").
>
> What we all really want to know is:
>
> Which of the previous calls to update() between
> point A and now actually scheduled the/a paint event.
In order to figure that (in a "brute-force kind of way") out you'd have to set
the breakpoint in the mainloop... doh!
Maybe there's another way: QWidget::update() is a slot, right? If you're
"lucky" those extra updates are triggered by someone calling that slot (via a
signal). Maybe a tool like "GammaRay" by KDAB would help in such a case? It
helps you tracking Qt signals (maybe even QEvents?). Haven't used it so far,
but maybe it's worth a try?
Cheers,
Oliver
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
