Qt-interest Archive, May 2007
how to accelerate the return from contextMenu?
Message 1 in thread
hi,
there's a qaction connected to time_consuming_slot() in a contextmenu;
when i popup the contextmenu and click this action, the main window
will look dead for a
long time;
how can i avoid the fake dead of main window?
time_consuming_slot() is a backend function and has nothing to do with the gui
regards
--
[ signature omitted ]
Message 2 in thread
On 12.05.07 19:23:45, jiang jefix wrote:
> hi,
> there's a qaction connected to time_consuming_slot() in a contextmenu;
> when i popup the contextmenu and click this action, the main window
> will look dead for a
> long time;
> how can i avoid the fake dead of main window?
Its not fake, your program spends its time in the time_consuming_slot().
To have a mainwindow that is still responding to user interaction move
the work into a separate thread. See the QThread documentation for more
info.
Andreas
--
[ signature omitted ]
Message 3 in thread
On 5/12/07, jiang jefix <jefix214@xxxxxxxxx> wrote:
>
> hi,
> there's a qaction connected to time_consuming_slot() in a contextmenu;
> when i popup the contextmenu and click this action, the main window
> will look dead for a
> long time;
> how can i avoid the fake dead of main window?
> time_consuming_slot() is a backend function and has nothing to do with the
> gui
> regards
As Andreas said, using a QThread for the time consuming operation would be
the best choice. It may be easier to add calls to
QApplication::processEvents() throughout the time consuming operation
(assuming that you can change the code within the operation).
Tom
Message 4 in thread
On 14.05.07 07:36:07, Tom Panning wrote:
> On 5/12/07, jiang jefix <jefix214@xxxxxxxxx> wrote:
> >
> >hi,
> >there's a qaction connected to time_consuming_slot() in a contextmenu;
> >when i popup the contextmenu and click this action, the main window
> >will look dead for a
> >long time;
> >how can i avoid the fake dead of main window?
> >time_consuming_slot() is a backend function and has nothing to do with the
> >gui
> >regards
>
> As Andreas said, using a QThread for the time consuming operation would be
> the best choice. It may be easier to add calls to
> QApplication::processEvents() throughout the time consuming operation
> (assuming that you can change the code within the operation).
Never use processEvents, unless you know exactly what you're doing. This
can have unwanted side effects, because all events that are waiting are
"executed".
Andreas
--
[ signature omitted ]
Message 5 in thread
On 5/14/07, Andreas Pakulat <apaku@xxxxxx> wrote:
>
> Never use processEvents, unless you know exactly what you're doing. This
> can have unwanted side effects, because all events that are waiting are
> "executed".
>
> Andreas
As opposed to having separate threads, where one thread is constantly
"executing" events while the other thread is doing something else? I can
understand the need to warn someone that calling processEvents can be mildly
dangerous (e.g., it is possible that an object that you're working with will
be destroyed in one of the event handlers), but saying "never use
processEvents, unless you know exactly what you're doing" is a bit overboard
-- particularly when the alternative is multiple threads. Also, the
documentation for processEvents suggests using it in exactly the manner that
I suggested: "You can call this function occasionally when your program is
busy performing a long operation (e.g. copying a file)."
Tom
Message 6 in thread
On 14.05.07 08:25:12, Tom Panning wrote:
> On 5/14/07, Andreas Pakulat <apaku@xxxxxx> wrote:
> >
> >Never use processEvents, unless you know exactly what you're doing. This
> >can have unwanted side effects, because all events that are waiting are
> >"executed".
> >
> >Andreas
>
>
> As opposed to having separate threads, where one thread is constantly
> "executing" events while the other thread is doing something else? I can
> understand the need to warn someone that calling processEvents can be mildly
> dangerous (e.g., it is possible that an object that you're working with will
> be destroyed in one of the event handlers), but saying "never use
> processEvents, unless you know exactly what you're doing" is a bit overboard
No its not, in the past I've seen and heard of many mis-uses of
processEvents to keep the GUI responsable, which caused bugs in the
applications that where really hard to track down. A proper
multi-thread-app is IMHO the better alternative, especially in such a
simple case where a loop is running in a different thread and posts
events to the gui application. This is sooo easy to implement, you don't
even need any locking for this, unless you want to stop the worker
thread. I really prefer this over using processEvents in one part of the
app and then forgetting about it, just to find weird bugs in a totally
remote part of the same application due to that processEvents call.
Andreas
--
[ signature omitted ]
Message 7 in thread
On 5/14/07, Andreas Pakulat <apaku@xxxxxx> wrote:
>
> On 14.05.07 08:25:12, Tom Panning wrote:
> > On 5/14/07, Andreas Pakulat <apaku@xxxxxx> wrote:
> > >
> > >Never use processEvents, unless you know exactly what you're doing.
> This
> > >can have unwanted side effects, because all events that are waiting are
> > >"executed".
> > >
> > >Andreas
> >
> >
> > As opposed to having separate threads, where one thread is constantly
> > "executing" events while the other thread is doing something else? I can
> > understand the need to warn someone that calling processEvents can be
> mildly
> > dangerous (e.g., it is possible that an object that you're working with
> will
> > be destroyed in one of the event handlers), but saying "never use
> > processEvents, unless you know exactly what you're doing" is a bit
> overboard
>
> No its not, in the past I've seen and heard of many mis-uses of
> processEvents to keep the GUI responsable, which caused bugs in the
> applications that where really hard to track down. A proper
> multi-thread-app is IMHO the better alternative, especially in such a
> simple case where a loop is running in a different thread and posts
> events to the gui application. <snip>
>
I agree with you on this, which is why my original post said that your
suggestion of multiple threads "would be the best choice". I've used Qt for
a while on many types of projects, and have seen plenty of uses of
processEvents without any adverse side effects. I have seen other Qt methods
that were abused and ultimately came back to haunt the project, but I can't
think of any bugs that were related to processEvents, even though the
biggest project that I've worked on was single-threaded and therefore
heavily relied on processEvents. I don't doubt that you've seen problems,
but our different experiences explain why I'm more comfortable with using
processEvents while you're skeptical of it.
Just out of curiousity, I'd be interested in hearing about any problems that
you've seen with it (possibly in a different thread or in a private
discussion, if you feel that would be more appropriate), since, as I said, I
work on a project that uses it pretty heavily. It's always good to know what
might be hiding under the surface of your code.
Jefix, I would suggest you look at using multiple threads to resolve your
issue. Threads are an important programming tool, and can be used in the
solution to many problems. If you decide you don't want to use them for this
problem, you have two alternative suggestions, but they aren't as powerful
as multi-threading.
Tom
Message 8 in thread
Thanks very much for all of you
And of course thread helped me
Thanks again for your kindness and patient.
2007/5/14, Tom Panning <lurchvt@xxxxxxxxx>:
>
> I agree with you on this, which is why my original post said that your
> suggestion of multiple threads "would be the best choice". I've used Qt for
> a while on many types of projects, and have seen plenty of uses of
> processEvents without any adverse side effects. I have seen other Qt methods
> that were abused and ultimately came back to haunt the project, but I can't
> think of any bugs that were related to processEvents, even though the
> biggest project that I've worked on was single-threaded and therefore
> heavily relied on processEvents. I don't doubt that you've seen problems,
> but our different experiences explain why I'm more comfortable with using
> processEvents while you're skeptical of it.
>
> Just out of curiousity, I'd be interested in hearing about any problems
> that you've seen with it (possibly in a different thread or in a private
> discussion, if you feel that would be more appropriate), since, as I said, I
> work on a project that uses it pretty heavily. It's always good to know what
> might be hiding under the surface of your code.
>
> Jefix, I would suggest you look at using multiple threads to resolve your
> issue. Threads are an important programming tool, and can be used in the
> solution to many problems. If you decide you don't want to use them for this
> problem, you have two alternative suggestions, but they aren't as powerful
> as multi-threading.
>
> Tom
>
--
[ signature omitted ]
Message 9 in thread
Hi,
I got another issue
i must process one time_consuming() and depend on its
return value to decide whether to process next func
if i create a thread to exec time_consuming() then gui will
not be blocked; but i cannot get the correct return value
from time_consuming() ,so the next func is always cannot
process,
Which I can think is to emit a signal when thread( exec
time_consuming() ) exits, but thanks to its time_consuming
When I got the signal main ( not thread ) has process a lot
far away,
How to fix it?
thanks
2007/5/14, jiang jefix <jefix214@xxxxxxxxx>:
> Thanks very much for all of you
> And of course thread helped me
> Thanks again for your kindness and patient.
>
>
> 2007/5/14, Tom Panning <lurchvt@xxxxxxxxx>:
>
> >
> > I agree with you on this, which is why my original post said that your
> > suggestion of multiple threads "would be the best choice". I've used Qt for
> > a while on many types of projects, and have seen plenty of uses of
> > processEvents without any adverse side effects. I have seen other Qt methods
> > that were abused and ultimately came back to haunt the project, but I can't
> > think of any bugs that were related to processEvents, even though the
> > biggest project that I've worked on was single-threaded and therefore
> > heavily relied on processEvents. I don't doubt that you've seen problems,
> > but our different experiences explain why I'm more comfortable with using
> > processEvents while you're skeptical of it.
> >
> > Just out of curiousity, I'd be interested in hearing about any problems
> > that you've seen with it (possibly in a different thread or in a private
> > discussion, if you feel that would be more appropriate), since, as I said, I
> > work on a project that uses it pretty heavily. It's always good to know what
> > might be hiding under the surface of your code.
> >
> > Jefix, I would suggest you look at using multiple threads to resolve your
> > issue. Threads are an important programming tool, and can be used in the
> > solution to many problems. If you decide you don't want to use them for this
> > problem, you have two alternative suggestions, but they aren't as powerful
> > as multi-threading.
> >
> > Tom
> >
>
>
> --
> qt 3.3.6
> kde 3.5
> thanks for your help
>
--
[ signature omitted ]
Message 10 in thread
On 14.05.07 22:43:24, jiang jefix wrote:
> Hi,
> I got another issue
> i must process one time_consuming() and depend on its
> return value to decide whether to process next func
> if i create a thread to exec time_consuming() then gui will
> not be blocked; but i cannot get the correct return value
> >from time_consuming() ,so the next func is always cannot
> process,
> Which I can think is to emit a signal when thread( exec
> time_consuming() ) exits, but thanks to its time_consuming
> When I got the signal main ( not thread ) has process a lot
> far away,
> How to fix it?
Well, if your gui depends on the time consuming operation to finish you
have to either redesign your gui to not do that or remove the threading
and live with not updating the window. You could try the processEvents
thing in your time-consuming function, maybe that helps...
Andreas
--
[ signature omitted ]
Message 11 in thread
> As Andreas said, using a QThread for the time consuming operation would
> be the best choice. It may be easier to add calls to
> QApplication::processEvents() throughout the time consuming operation
> (assuming that you can change the code within the operation).
Excuse me for throwing my 5 cents in, but perhaps it would be a good
idea to skip the additional overhead of a time consuming thread if
possible. IMHO Jefix should check if what he wants to achieve isn't
better implemented using QTimer...
Martin
--
[ signature omitted ]
