> This is a multi-part message in MIME format.
> --------------080402080309030507070002
>
Thanks Albrecht, I have copied this to a file and will review later, at first
glance it seems to be an evolved version of your earlier button example which I
found useful working last night. The threads example posted by Ian I did not
get to look at as I had copied a resource packing example I was looking at
elsewhere into the file without realising. I was a little confused when I
started reading through my file titled âFLTK threads exampleâ haha.
Anyway, I made progress last night, the button example callback had me really
confused at first, the prototypes and calls just werenât adding up as I tried
to hack a working version into an exisiting test project. Also when I ran the
actual example itself in the debugger I was amazed to see I could not âget
back outâ of the callback function, âby stepâ requests in the normal way.
I thought what theâ¦! And âhow does it know how to exit?â âHow does it
know to even do this same callback again?â Then I had a bath, and like a
modern day Archimedes I had my (I hope) Eureka moment! Something like this
came to me:
The program flow could not be followed in the debugger in the normal way
because nothing else had happened. The callback had completed and the lower
level GUI loop had again taken over, the only time anything was going to go
anywhere was if another event triggered a different callback, and it exits the
whole program when required because âexitâ is a callback too!
As I say the call to âcallback()â code and user defined function
definition had me confused also.
There seem to be several overloaded versions of callback() could anybody
illustrate those for me?
I see that as a minimum it takes a pointer to a function, does the function
parameter (ie the user defined callback function) have to be a function that
takes an Fl_widget* as a parameter? Or is this just a good idea as it is
probably going to be used internally In user callback implementation for
redraw() or other operations?
And what is the void* parameter in function button_cb for?
I managed to get this working in my program and I used Fl::Check() called
within a loop that counted to a million and output it to a textbox, whenever a
rudimentary âtimerâ variable reached10, in this was I managed to get my
first look at what I originally was after, watching a variable been written
quickly to the output box, itran nice and fast with only a little flickering,
probably due to the check() call? And was certainly fit for purpose, only
problem is, as expected it âhosedâ the CPU ;-> Until I tell it not to run
at full whack then this is going to happen no matter what the spec of the
machine I suppose. I have just told the program to âGOâ so I think I could
afford to cap the framerate (if that is accessible in FLTK?) a little and
reduce CPU that way, but I think the clear answer is really to go with the
multithreading.
My only other issue was I could only get this to work last night using a global
object, when I tried to define a callback within a class and then use it later.
I tried to cast the Fl_Widget* as a window, within mycallback definition which
worked fine, but I wanted it to be MY window, which was constructed with an
output box⦠ahh I see⦠I should have cast the widget as an output box???
I have added some additional comments to the code below to show my
understanding so far.
// global variables for easier coding
static int state = 0;
// simple callback function
void button_cb (Fl_Widget *w, void *) {
Fl_Button *b = (Fl_Button *)w; // Cast widget to the required local type
if (!state) { //if block checks if any event occured at all (to
the button that sent the callback)
//why does this not trigger when you get a
'mouseover' type event?
//if this is just checking if(1) or if(0) surely
mouseover button = 1?
b->label (" - S T O P -");
state = 1;
} else {
b->label ("S T A R T");
state = 0;
}
b->redraw(); //This is not always neccesary, depending on widget
}
int main(int argc, char **argv) {
//
//
//
button->callback(button_cb); // callback takes function pointer parameter,
allows for great flexibility
//
//
return Fl::run(); //low level event loop, not exposed.
}
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
