Olivier wrote:
Flash Gordon a écrit :
[...]
>Since this is really about how it is best to do things in GTK
[...]
Well, I wondered ... The signal handling is gtk stuff ok.
But the way to do that inside is way out of gtk to me.
Seems more like my dear and lost catch/throw mecanism
or exception stuff. I set the background with gtk to be
clear but that could have been anything, even a shell
thing. I agree that it has to do with inputs and outputs
of a program -- but many programs do have both, even
in C, no ?
C had no exception handling. The only mechanisms it has for your program
to detect some asynchronous external event are either if the event
causes a signal which you catch with a signal handler, you could then
set a flag (of type volatile sig_atomic_t) which you could regularly
test in you long running calculation, or you regularly polling to see if
the external condition is true. Neither method is very good for handling
this king of thing. There may, on the other hand, be a good way with
GTK, for example using two threads (which C knows nothing about) one for
the user interaction and one for the long running process. The GTK
people will know whether this or some other solution works best with GTK
(I know that on one Delphi application separate threads for user
interface and high speed serial comms worked well) but we won't here.
I'm only suggesting where you are likely to get the best advice for what
is a very common problem for people writing GUI based applications.
By the way, if you are executing code asynchronously (i.e. handling GUI
events) using any other mechanism that standard C signals then the C
language does not tell you how to avoid synchronisation problems, e.g.
your main code being half way through reading a variable when the
asynchronous code writes to it thus causing you to read half of one
value and half of another, even volatile sig_atomic_t is not guaranteed
for that, only for C signals.
--
Flash Gordon.