On 9/4/06, franks-muc@web.de <franks-muc@web.de> wrote:

> I am now able to  get correct behavior  when starting from the repl or by evaluating  (run-window 'my-test) in an editor, but only changing this parameter to a lower amt: *event-loop-delay*. The value in CVS is 0.08 . I tried 0.02 and got the keystrokes OK, did not experiment further. The problem is that the ACL IDE is then locked out while a Celtk window is open.
>
> Since entry fields work for me using Run Project in ACL with the *event-loop-delay* parameter at 0.08, I think I will leave it that way since that is how I test anyway.
>
> Let me know if a lower value for *event-loop-delay* works for you.
>
> kt
>
>

Reducing *event-loop-delay* is the solution. Already 0.075 let all key strokes show up in the entry field (at 100% CPU
usage by acl).


Yeah, I think any vale that low is effectively zero because it is below some minimum granularity. Also, my guess is that you are now locked out of the ACL IDE while a Celtk window is open. That could make debugging pretty hard. A number of solutions occur to me, including adjusting the delay intelligently when the  TK window loses the "focus" aka deactivates, or even just a whole new approach to the event loop. Unfortunately I will not be able to explore these until  my own project demands it, but  I might poke around a little now and again, and I will be happy to help anyone else with ideas if they choose to explore.

The new event loop approach is probably the only way to avoid pegging the CPU. I forget what happens if we just give the whole event loop to Tcl and settle for callbacks. Possibly we are looking at hogging the CPU during development, then switching to a different approach for delivered apps, all controlled by conditional compilation.

kt

ps. Cells fans, sorry for the spam; if the Celtk traffic keeps up I will look at getting a new project, or moving Celtk from Cells to Cello and supporting it fromt here. kt