I have two QWidgets, w1 and w2. The two widgets contain complementary information, so they both need to be redrawn at the same time. w1 is updated via repaint(), which works fine. I call repaint() instead of update() because update() doesn’t redraw w1 while I’m dragging the mouse around, and dragging the mouse is one way the user can change the display. w1.paintEvent() calls w2.repaint(), which causes a crash. It appears the heap is corrupted. The call stack doesn’t look like infinite recursion, but I doubt the call stack is trustworthy. If w2.update() is called instead, there’s no crash but w2’s display lags w1’s in time. w2 doesn’t do anything except draw itself, so it shouldn’t be possible for w2.repaint() to cause recursion.
I’m running on Win7. I have an exe with both Win7 windows and Qt windows in it. All of the Qt code is in its own DLL. This makes it possible to incrementally replace the Win7 windows with Qt windows over time while continuing to release the product. If instead of dragging the mouse in a Qt window I drag the mouse in a corresponding Win7 window and send notifications to the Qt window, Qt doesn’t have to deal with the mouse drag messages directly and I can call w1.update() and w2.update() and w1 and w2 are redrawn at the same time.
Is there a way to make update() higher priority than mouse drag messages?
This is easy enough to workaround in this case as w1 and w2 are both in a QVBoxLayout, so I could simply merge w2’s functionality into w1, but I’d like to be able to synchronize widgets that aren’t so conveniently lined up.
↧