[Qt-interest] QWidget::setCursor() and qApp->processEvents()

[Atlant Schmidt]

John:

  No, Josh's problem is more fundamental and it's caused
  one of those aspects of Qt that isn't obvious to the
  newcomer.

  Consider this pseudo-code activated by a signal:

  MyClass::my_slot(void)
    {
      button_1->hide();
      button-2->show();
      button_3->disable();
      button_3->show();
      do_several_seconds_of_lengthy_computation();
    }


  When do the changes to the buttons appear to the user?
  They appear *AFTER* the several seconds of lengthy
  computation. This comes as a real surprise to many
  folks, but it makes perfectly good sense once you
  understand how Qt works.

  Qt doesn't actually draw anything as you change the
  status of the various buttons; it merely notes that
  the buttons eventually need to be repainted. And it
  will get around to doing all of that repainting, all
  at once, once it gets back to its main event loop.

  Ordinarily, this is a good thing; it "merges" multiple
  changes that you might make to a single widget (as I
  did with "button_3") and in that way it optimizes all
  of the repaint activity. But if you do something like
  Josh has done (or my pseudocode has done), it doesn't
  have the effect you expected because you don't get
  back to the Qt event loop in a timely fashion.

  But forcing a repaint before the lengthy calculation
  "flushes out" all of those pending repaint events so
  the user can see them on the screen.

  Alternatively, I'm coming to believe that any serious
  Qt app really needs a separate thread handling the UI
  so that the UI stays adequately responsive even in the
  face of other work that the app is doing; all single-
  threaded Qt apps are little more than nice demonstrations/
  toys and unsuited for serious work.

                        Atlant


-----Original Message-----
From: qt-interest-bounces at trolltech.com [mailto:qt-interest-bounces at trolltech.com] On Behalf Of John McClurkin
Sent: Thursday, July 29, 2010 7:38 AM
To: qt-interest at trolltech.com
Subject: Re: [Qt-interest] QWidget::setCursor() and qApp->processEvents()

Josh wrote:
> Hello all,
>
> Before I do some calculations in my program I want to set the cursor
> using: viewport()->setCursor(Qt::WaitCursor);
>
> However, the cursor doesn't change because of the calculations. I don't
> want to call qApp->processEvents() during the calculations because I
> actually want the ui *not* to respond while the calculations are taking
> place. So I was able to get the cursor to update BEFORE the calculations
> as follows:
>
> qApp->processEvents();
> qApp->processEvents();
> viewport()->setCursor(Qt::WaitCursor); for(int i=0; i<20; i++)
>   qApp->processEvents();
> do my calculations...
>
> This is obviously a hack. I needed to call processEvents 20 times for
> the cursor to update. Any less and the cursor wouldn't update before my
> calculations. I would assume that on different machines I might need
> different number of calls to processEvents(), which is undesirable.
> Anyone have any ideas on the correct way to do this?
>
> So in summary:
> How can I make sure the cursor is changed before doing my calculations
> when I don't want to call processEvents() during my calculations?
>

AFAIR, processEvents() collapses all pending requests into a single
call. Your mulitple calls on qApp->processEvents() essentially
constitute a busy loop that halts your program until qApp processes
events. You might play around with QTimer, setting a timeout after
setCursor() and calling processEvents() in the timer slot.

_______________________________________________
Qt-interest mailing list
Qt-interest at trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-interest

This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.