> What are the main differences between the GUI program flow > and the type shown above?
That can work - but the issue is with how you handle the i/o. In a console app, i/o via printf (et al) is pretty much synchronous - your program calls printf, and stuff appears on the console. (Actually this is a gross simplification but lets pretend for now that it is true...) In a GUI context, that tends not to be the case; the GUI rendering takes a significant amount of the CPU (in many programs it can be the dominant element) so you do not necessarily want to redraw the GUI for every change - especially if the updates are fast, i.e. faster than the display refresh rate (or indeed faster than a human operator can perceive.) So fltk (in common with many systems) queues up the changes and flushes them out to the display at a more "moderate" rate, asynchronously to your programs flow. But to do that, you need to give it some CPU time. Generally, GUI programs are driven "by the GUI" and it is that flow that determines program operation. However, you are coming at this from the opposite end - i.e. your program flow wants to drive the GUI, and it is this disconnect that is causing the problem. It is a shift in perspective that many people encounter when getting into GUI coding... In a single threaded program, this can be worked around by having your "do algorithm" step pump the fltk engine by calling Fl::check(); periodically. That will let your code work and should more or less do the Right Thing. However, what I would do is have the program run the GUI, then have the GUI start a worker thread that runs my (lightly modified) console app. The modified console app would then "print" to the GUI interface (still running in the main thread) which would display the updates on the screen - and since it is in its own thread separate to the "console app" I don't have to worry so much about scheduling asynchronous updates or etc., as the underlying OS deals with all that. The next step along might be to make your console app read/write to a socket and have the GUI standalone read/write to a socket and handle all the i/o in that way. That's a bit more work to set up of course, but once it is done it opens up the possibility of running your app remotely on a server or etc. pretty much "for free" if you want it... I think I have an crude example of the threading approach somewhere - if I find it, I'll post it along... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
