Re: [gtkmm] progress bar headache

[Chris Vine <chris cvine freeserve co uk>]

On Thursday 06 May 2004 07:57, Alberto Paro wrote:

> junk siology net wrote:
> | lo, ive got this code.....
> |
> | ive got a timeout event which makes a progress bar pulse() no
> | problem at all, the idea is that let_progress_go (boolean) if true
> | will allow the pulse command to happen, if not it will skip it (i
> | used an if statement for that) -- still no trouble.
> |
> | the problem is that the progress bar isnt started during this block
> | of code, (when i set let_progress_g to true). and even if i put the
> | pulse() call directly in the loop at point A it dosnt work.

[snip]

> Popen locks the interface.
> You have to thread the md5 operation. Look at some past message thread
> to thread and interface update.

Or if the OP is writing a non-threaded (or more accurately uni-threaded) 
application and can avoid having to use fgets() for C string input (that is, 
he can make do with reading into a buffer array and obtaining formatted 
output from that), he can just use a main loop event handler (ie, use the 
normal pipe(), fork() and exec*() approach, make the read pipe file 
descriptor non-blocking with fcntl(), and then plumb it into the main loop by 
connecting it to an event handler with  Glib::signal_io().connect()).

Depending on what he is trying to do this could be easier than employing 
threading.  For example, if his program needs to launch other programs with a 
fork() and exec*() call, IEEE POSIX Std 1003.1 requires that in a 
multi-threaded program all system calls between the fork() and exec() calls 
are async-signal-safe.  No such requirement is imposed in a single threaded 
program.

Chris