-
-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
onEvent does not always update display #191
Comments
It's because threepenny is now batching the calls. Unfortunately it only forces when you call a function. That's why in drumMachine it uses a get UI.checked box. |
Thanks, flushCallBuffer worked for me.
I wonder, is there any use of onEvent where you would not want to
display any updates that were made? Perhaps onEvent should automically
call flushCallBuffer.
…--
see shy jo
|
From what i understand from flushCallBuffer. You want to call it as few times as possible. Currently because all FFI Calls (that return values) need to call it to get the value, we endup flushing in every FFI call. Ideally all sequential runEval in the server can be batched together. Simply using onEvent for two events that trigger at the same time would lead to unnecessary flushing pushing twice to the client. |
This mode is like `BufferRun`, but will flush the buffer at every `onEvent` as well. This should make the library less confusing to use in most circumstances.
The new commit above introduces a new default buffering mode, called |
This mode is like `BufferRun`, but will flush the buffer at every `onEvent` as well. This should make the library less confusing to use in most circumstances.
A program using onEvent with a timer does not always update the display each time the
timer fires. This example program shows the problem:
That should, I think, scroll "foo" across the top of the screen. However, it never actually moves.
Uncommenting the commented-out line makes the display update. I don't understand why.
Note that samples/DrumMachine.hs seems to only avoid this problem because it happens to call "get UI.checked box" when playing a sample.
The text was updated successfully, but these errors were encountered: