The program I'm writing has to do extensive computation while
updating the GUI (as well as updating a possiblity very massive
list). As you can imagine, this freezes up the gui. While one solution
is to thread the processing, it seems less then optimal to me because
then it gets complicated with threads all over the place fast.
What I'd really like to do is check for pending events between
a series of calculations and then process them. While I know that
the wxApp class offers functions to do this (such as Pending ()
and Dispatch () ), the problem is that my code lies in libraries
and I don't necessarily have access to the wxApp instance that I
created. What I'd really like are global functions that give me this
exact same functionality so that I can check for events.
I guess what's really bothering me about this is that having the
application as only an instance of wxApp forces me to deal with some
name mangling and have my application structured so that all my
libraries might need to know about the main application. Any solution
to this would be really appreciated.
What I'd really like to do is check for pending events between
a series of calculations and then process them. While I know that
the wxApp class offers functions to do this (such as Pending ()
and Dispatch () ), the problem is that my code lies in libraries
and I don't necessarily have access to the wxApp instance that I
created. What I'd really like are global functions that give me this
exact same functionality so that I can check for events.
may consider an alternative approach, I found useful _sometimes_:
According to Alan Cox:
<<Threads are for people, who cannot implement state machines....>>
I'm taking a long processing job, breaking it into pieces, and do
each one at a time, triggered by a one shot timer, as long as things
aren't finished... May be not the most elegant approach, but fits
UI requirements nicely (think of "Cancel").
Yesterday, I finished the postscript printing module of my upcomming
FaxViewer this way. It has to generate PS with tiff2ps, merge and
mangle borders in them, and send this through the print pipe, which
can be something like: "psnup -2 | sendfax -nmd ...". Most hairy was
stopping the print pipe. Solved this by sending a SIGHUP to my process
group, and ignoring this signal in main.
Timer related performance penalty is pretty small:
generating 9 copies of a 14 page fax results in 126 pages, psnuped by 4:
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]
[18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32]
Wrote 32 pages, 62883082 bytes
printjob used: 1:42 min
Cheers,
Hans-Peter
···
On Sunday, 3. March 2002 02:12, Michael Gilfix wrote:
The program I'm writing has to do extensive computation while
updating the GUI (as well as updating a possiblity very massive
list). As you can imagine, this freezes up the gui. While one solution
is to thread the processing, it seems less then optimal to me because
then it gets complicated with threads all over the place fast.
What I'd really like to do is check for pending events between
a series of calculations and then process them. While I know that
the wxApp class offers functions to do this (such as Pending ()
and Dispatch () ), the problem is that my code lies in libraries
and I don't necessarily have access to the wxApp instance that I
created. What I'd really like are global functions that give me this
exact same functionality so that I can check for events.
I guess what's really bothering me about this is that having the
application as only an instance of wxApp forces me to deal with some
name mangling and have my application structured so that all my
libraries might need to know about the main application. Any solution
to this would be really appreciated.
So these functions are not tied to the actual application instance?
Maybe I'm reading too much into the object interface then. If the
whole application shares a global queue, I guess it doesn't
matter much. I'll give it a shot then.
-- Mike
···
On Sun, Mar 03 @ 03:52, Magnus Lyckå wrote:
At 20:12 2002-03-02 -0500, Michael Gilfix wrote:
> What I'd really like to do is check for pending events between
>a series of calculations and then process them. While I know that
>the wxApp class offers functions to do this (such as Pending ()
>and Dispatch () ), the problem is that my code lies in libraries
>and I don't necessarily have access to the wxApp instance that I
>created. What I'd really like are global functions that give me this
>exact same functionality so that I can check for events.
may consider an alternative approach, I found useful _sometimes_:
According to Alan Cox:
<<Threads are for people, who cannot implement state machines....>>
While I'd agree with this on some level, threads are there to
avoid writing a lot of unnecessarily messy code.
I'm taking a long processing job, breaking it into pieces, and do
each one at a time, triggered by a one shot timer, as long as things
aren't finished... May be not the most elegant approach, but fits
UI requirements nicely (think of "Cancel").
I did a similar thing in a perl project where threading wasn't
really supported. I wrote a schedule for async handlers and
essentially added them into my queue. I didn't have to care about
relinquishing approaches but I could have just changed the handlers to
reschedule themselves after a certain amount of time elapsed. But
I'd rather use threading if it's available. Just much more elegant.
Yesterday, I finished the postscript printing module of my upcomming
FaxViewer this way. It has to generate PS with tiff2ps, merge and
mangle borders in them, and send this through the print pipe, which
can be something like: "psnup -2 | sendfax -nmd ...". Most hairy was
stopping the print pipe. Solved this by sending a SIGHUP to my process
group, and ignoring this signal in main.
Timer related performance penalty is pretty small:
generating 9 copies of a 14 page fax results in 126 pages, psnuped by 4:
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]
[18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32]
Wrote 32 pages, 62883082 bytes
printjob used: 1:42 min
The program I'm writing has to do extensive computation while
updating the GUI (as well as updating a possiblity very massive
list). As you can imagine, this freezes up the gui. While one solution
is to thread the processing, it seems less then optimal to me because
then it gets complicated with threads all over the place fast.
So these functions are not tied to the actual application instance?
wxGetApp() returns the actual application instance.
Maybe I'm reading too much into the object interface then. If the
whole application shares a global queue, I guess it doesn't
matter much. I'll give it a shot then.
While it is possible to implement your own MainLoop with these methods, you
are probably better off not to. You loose the benefit of being able to wait
in the system message queue for the next event to happen. Essentially you
switch from waiting for an event to polling for an event, and chew up CPU
cycles while doing it. See http://wiki.wxpython.org/index.cgi/LongRunningTasks for alternatives.
···
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython!
Cool. Thanks for the reference. I ended up using threads in the
end. Was the simplest way and a bit of restructuring of the code
made it elegant.
···
On Mon, Mar 04 @ 09:20, Robin Dunn wrote:
> The program I'm writing has to do extensive computation while
> updating the GUI (as well as updating a possiblity very massive
> list). As you can imagine, this freezes up the gui. While one solution
> is to thread the processing, it seems less then optimal to me because
> then it gets complicated with threads all over the place fast.