Run next code on same block when event occurs.

lightburst · **Joined:** Thu Jul 28, 2011 5:14 pm **Posts:** 12

Basically I have here a Quicksort demo. I was asked to put some sort of delay before the next recursive call, for illustration purposes.

Code:

g_timeout_add_seconds(1, emit_func, SOME_DATA);

Code:

while(gtk_event_pending()){ // run next recursive call after a certain interval, wait for event.
   gtk_main_iteration();
}
recursive_func(param);

Doesn't work. For some reason, the loop exists after gtk_main_iteration(), or maybe after some few calls to it.

I also tried:

Code:

while(flag){
   gtk_main_iteration();
   if(gtk_events_pending()) 
      flag = FALSE;
}

with the same problem.

I'm thinking of doing maybe doing a brute loop using a global flag that will be toggled via a timeout function, and alternatively counting via a clock() construct. But I don't want to do that, particularly in GTK+. I'm trying to make things as event driven as possible as to not hog CPU resources.

Sleep() doesn't work either as the whole program just stops (or block?), literally without anything on the GUI when it's suppose to.

zerohour · **Posted:** Mon Dec 19, 2011 9:18 pm

What version of Gtk are you using and on what platform?
I would read Tadeboro's blog: http://tadeboro.blogspot.com/2009/06/multi-threaded-gtk-applications.html

kepica · **Posted:** Tue Dec 20, 2011 7:05 am

gtk_main_iteration with gtk_events_pending does NOT make any delay !
if there is no events, it just skip to your calculation or whatever you do...
you have to place you main task in clock - how you call it emit_func ?

EDIT: thanks errol for a clearing that. that was my first thought, to use volatile. I delete it, just a minute before errol made his post

errol · **Posted:** Tue Dec 20, 2011 7:43 am

If the original poster can be a bit more detailed in what they want to do rather than what they have tried. Then I might be able to give a detailed answer, instead of trying to guess what you might want!

Going backwards. The use of "volatile" is incorrect and should not be used. At best the compiler will generate less than optimal code. If you then start using threads and read or write directly to it without using an atomic operation from multiple threads then the result could be undefined.

As zerohour stated, threads may well be best for you. Your main thread deals ONLY with the GUI and your worker thread ONLY does the quick sort, this way you avoid the need to use the global GDK lock. You will need some point in your quick sort to do the requested pauses and to communicate to your main thread its progress using some form of inter process communication (IPC). There are many ways to do this, depending on what data you want to pass so I will not list them here, but GLib has ways to do this built in.

GTK+ Forums

Run next code on same block when event occurs.

Who is online