Strange responsiveness/repaint behavior.

[JoeBauman]

Hi folks -

My application plots real-time sensor data and also allows the user to send very short commands to HW over a serial port. The strange behavior is that through some combination of interaction (I haven't been able to consistently reproduce it), the application window stops repainting itself. When it gets into this "mode", if I move the whole application window it refreshes (redraws? repaints?) everything and then stops again when the window stops moving. For example:

- If I click on a LineEdit nothing happens - but if I then move the window slightly then the cursor appears at the end of the text. It doesn't blink like it should unless I keep moving the window to keep it refreshing.

- The plot displaying the incoming data stops updating - but when I move the window it refreshes and shows enough acquired data to indicate that everything continues to run correctly in the background.

Does anyone have any suggestions as to what might have happened or what I can look for to explain this behavior?

Thanks much,

Joe.

[d_stranz]

Using multithreading? If so, has the GUI thread gotten into a state where it is blocked waiting for input from the sensor or the serial port? From your comment about "in the background" it implies that you are multithreading and have probably gotten the app into some kind of deadlock situation.

If your app is being kept so busy that the event loop is unable to execute, this could also cause unresponsiveness, although moving the window shouldn't necessarily cause things to magically repair themselves unless moving the window sends a repaint which bypasses the event loop.

[JoeBauman]

Thanks for the reply.

It looks like the culprit here was an issue or two in the QExtSerialPort module that I am using. Shortly after posting here I found a couple bugs in the QExtSerialPort bug list that deal with this issue. Something about the way the serial port handles events - or, more precisely, the way it doesn't stop trying to handle events after you close the port - is interfering with the rest of the events in the system.

Odd, because it wasn't the usual incorrect thread usage or "too busy to handle events" behavior.

Anyway, hope this helps someone else avoid the same problem!

Joe.