> Generally said, what I am trying to do is to make separate thread for > displaying each window. I thought about creating multithreaded > callback function for each window's redraw,or redesigning main loop's > work, or something like that.The aim is to make each window run > absolutely separately,so that if there is some ,for example, endless > loop in one of it, you 'd have a possibility to switch to another > window and continue work there. I know that maybe it's kind of wrong > idea, but maybe you'll give me some clues for that, I really need that. > thanks in advance.
We might need to get more insight into what you actually need to achieve, before we can know how best to advise you, as there are multiple ways to get to the endpoint you describe here... Which is best for you, will depend on what you are hoping to achieve. So, anyway, some notes: - most host platforms only have a single graphics card, and access to the display through that cards is inherently serialised and single threaded - in particular, modifying the GUI context from multiple threads can be fraught with difficulties - threading is an option, but there are issues you need to take care of - many apps achieve the same effect by use of timer callbacks from a single thread - most host platforms very much prefer it if you access the graphics card from the "main" thread of your app, i.e. the thread in which the main() function was called; this thread is often "anointed" with special privileges that other child threads don't get by default... In particular creating / deleting / hiding / showing windows from a child thread often goes quite badly! (Only do that from the main() thread as a rule.) What I usually do is put all the GUI work in the main() thread, and spawn off child threads to do the actual work - these threads communicate back to the GUI thread via the Fl::awake(...) mechanism. However, with judicious use of Fl::lock() and Fl::unlock() the child threads can safely update widgets and windows that the main() thread has created. (Though the child threads must not call redraw() on the widgets - again, use of Fl::awake() is the way.) That's the basics for using multiple threads with multiple windows, I think - did that make sense? Did it help? The alternative (using multiple timer callbacks in a single thread to "emulate" multiple threads, might actually be simpler in many cases..) What is it you need to achieve? Selex ES 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-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
