Problems with recursive calls to QWidget::paintEvent

[warchild]

I have encountered several problems with QWidget::paintEvent in a custom widget:

1. Calling QMessageBox from inside paintEvent causes recursive paints and "QWidget::repaint: Recursive repaint detected" message in the output.

2. A crash inside paintEvent causes recursive paints and even worse the debugger end up in code not even close to the code where crash happens because of trashed stack, so you basically have to guess where it crashed.

Quite annoying problems. Am I doing something wrong?

[mrjj]

Hi
When you pop a QMessageBox over yourself (the widget), it must be repainted when removed so
it looks as intended. (redrawing the area that was covered)

So its not allowed to pop new windows/widget in paintEvent as that will lead to infinite recursion by its very nature.

Same with resizing in the resizeEvent. bad idea.

So its not a bug or anything. it HAS to be that way.

So simply do not pop things in paintEvent. PaintEvent is fot painting

So yes, its wrong to open new windows in paintEvent and as soon as you stop doing that both 1 and 2 will go away :)

That said - its possible to some degree to prevent the infinite recursion using status flag but
often a better solution exists.

So what is the goal of the code ?

[warchild]

The paintEvent is used for rendering graphics (OpenGL) it this case. I'm not sure if I can agree with you. For example removing the QMessageBox in nr 1. the problem nr 2. still exists. If there is a crash inside the rendering code (opengl api code) you still end up i a recursive paintEvent call when jumping out into debugger (qtcreator in this case). So without nr 1. problem nr 2. still exists. I was using QMessageBox in a custom assert function to popup a assertion failed message. Changing that to a standard cassert call solves the problem. So when a system message box pops upp for some reason no recursive paintEvent is triggered even tho the message box covers the widget.