On Friday, June 17, 2022 at 4:14:00 AM UTC-7 imacarthur wrote:
On Fri, 17 Jun 2022 at 11:44, Albrecht Schlosser wrote:
> On 6/17/22 01:58 Bill Spitzak wrote:
> > I think what is happening is the RELEASE event is getting lost, so the
> > counter thinks the button is pressed and keeps incrementing.
> Yes, that was my first thought too and my first demo program opened a
> modal window in the callback which directs the FL_RELEASE event to the
> modal window and thus it is lost for the Fl_Counter widget. But this is
> only one of the issues.
So... I haven't really been following this, but I'm concerned that
having a callback that runs for a significant time period might be a
tricky problem to solve anyway.
Whilst the button callback is "in flight" it seems that there could,
potentially, always be a risk of missing some events being delivered.
I think Windows tends to queue 'em all up, but I'm not sure to what
extent that happens for other OS, or how robust that really is...
Certainly on Windows if you block event delivery for "long enough"
things can start to get weird...
So it is useful to understand how/why the rebase event is getting lost
but I' also concerned that whatever we do may not be able to fix all
Rob, if you break the timing dependency out - that is, have the button
cb return "instantly" and then perform the time consuming
computations in a different thread (say) does that then make things
"work" - i.e. is it is possible to demonstrate that it is timing that
is the crux here, or is there something more going on?
I don't see a practical way to do this (certainly not in the short term). My program is not thread safe and we take a long time to come back in a number of situations. This program and its ancestors have been using FLTK (and XForms and SGI Forms before that) since the early 1990's -- at different times, computers get faster, but our calculations also get more complex. Most things maintain the illusion of happening 'instantly', but users can create arbitrarily complex models -- which can take time to update.
That said, I can certainly load up a trivially simple model -- and when I do that, I never see the repeated events or the infinite loop. Everything works as normal. So while I can't return from the callback "instantly" by spawning a new thread -- if I return "fast enough", I never see the problem.
I will certainly take free advice -- long-term, how would I go about re-designing my program to improve this interactivity? I imagine a separate thread for most of my program -- with a wait loop listening for events -- then FLTK sends events over to that separate thread. It seems to me that this would not improve the user's experience at all. While the GUI would return instantly and allow the user to continue queueing up commands -- the background engine would still take time and would have to handle those requests in series (and in the order they were given).
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/a5d05678-9bda-44f2-9c99-5bae97c49580n%40googlegroups.com.
[ Direct Link to Message ]