Graham Stokes wrote:
> Hi,
> 
> Anybody out there faced this ? (the code below is actually just the core 
> of the "babelfish" example). But there's a "flaw" in the code that isn't 
> mentioned in the documentation. Specifically, when the button press 
> invokes procAll, any updates to the widgets are sort of "queued up" 
> until procAll finishes and only then are they applied - I discovered 
> this by painstaking trial and error. What if I want procAll to go away 
> and process a load of stuff that might take 20 minutes, but I want to 
> update the screen with messages about progress and stuff. I just find 
> that I get nothing until procAll  ends. Clearly I've missed a step with 
> setting up the messaging, but the documentation is persuading me that 
> there's nothing more to do.
> 
> Can anybody tell me what's wrong with the code below ? Why won't the 
> text field show the text as soon as the data target is updated as the 
> documentation implies it will ? Other widgets behave in a similar 
> fashion with the exception of the progress bar which will update 
> immediately. Very peculiar. Any help appreciated.

I think your diagnosis is right. Your ruby code is never giving Fox a 
chance to update the GUI. You can fix it by explicitly sharing time with 
Fox:

   def procAll(sender, sel, ptr)
     @stringVal.value += "This is new text\n"
     500.times do
       getApp.runOneEvent
       sleep 0.01 # or do some fraction of your processing
     end
   end

There's still a little delay, but it's probably acceptable.

You might want to do the runOneEvent calls in one ruby thread, and do 
your non-GUI processing in another.

In some cases, you really want "as soon as" semantics, and in those a 
good alternative to FXDataTarget is my FoxTails lib. See 
http://redshift.sourceforge.net/foxtails or search the fxruby-users list 
archive.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407