Wonderful, it works now perfectly, I use your solution, using a
"timeout" to control the "thread". The "thread" write his progress in  
global
structure variables (volume, duration) and "timeout" read these
values and refresh the popup window (every 0.1 sec). Now "thread" do
nothing with GUI, only "timeout" interact with it between "lock" and
"unlock" call.
   I don't print each packet only the percentage of total size
and only if this percentage is different that previous (max 100 refresh).
   It's now easy to program multiple concurrents access with for each
a couple "timeout/thread" (have just one small problem to maintain two
or more popup window over the GUI but it's just a visual problem)

   Many thanks Ian.

Patrick

Le Mon, 22 Jun 2009 09:26:31 -0000, MacArthur, Ian (SELEX GALILEO, UK)  
<[email protected]> a écrit:

>
>>     It's a problem, i can't use "lock" on Windows OS in this
>> thread, the
>> first "Fl::lock" freeze the thread ... and the GUI.
>>     Without this "lock" it works, i dedicated a popup window
>> to this thread
>> and I hope to avoid conflicts.
>
> I think we need to figure out why that happens.
> The code needs to be written so that it will not freeze here, your
> thread needs to try and obtain the lock when (and only when) it has
> something to update, and probably also wants to "ration" it so that you
> only update the GUI at a slow rate (say 20Hz or less would probably be
> enough.)
> For example, trying to update the GUI for every single packet you
> receive over a link might by much too often, causing the system to
> become bogged-down trying to refresh the GUI all the time... Is that
> possibly what happens?
>
> Updating the GUI context without first obtaining the lock will lead to
> corruption, so I would strongly recommend against doing that.
>
> For what it is worth, updating a progress bar or similar can be easily
> done from the main thread anyway - just have the "worker" thread fill in
> a shared variable with the current count (say) and have the main thread
> check that count via Fl::add_timeout() to update the progress bar in a
> timely fashion. That sort of thing. But you probably know all this
> already, of course.
>
>
>
>
>
> SELEX Sensors and Airborne Systems Limited
> 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

Reply via email to