Unconditional timer

I am curious is there is a way to create an unconditional timer in a Xojo app.
If you, for example have a long response time from a database-connection like Postgres, or close loops, timers will not fire meanwhile. Of course I can go using a helper app and setup communication with my main app, but that’s not a very dignified way to do it for just a simple application.

B.t.w I did also try TimerMBS.

Putting your database connection in a Thread should let the Timers fire on schedule.

Events and threading are compex, but there’s a fairly simply way to think about it:

The basic rules in Xojo are:

  • While an Event handler is running, no other Events will run (they will be queued up in order for later). Events include things like button.action, timer.action, menuhandlers, keyboard and mouse clicks, App.Open, Window.Open, Window.Activate, etc. Pretty much anything listed as an Event is an event handler in Xojo. This means that if your Postgres call is initiated from wihtin an Event handler, all other handlers are blocked, until it returns. This is true even if the Postgres call yields.
  • While an Event handler is running, Threads continue to run. But this happens only if the event handler code (and any code that it calls) actually Yields.

Yields happen

  • at Loop boundaries (but these can be blocked using #pragma DisableBackgroundTasks)
  • by calling Yield() or App.YieldToNextThread()
  • by calling App.SleepCurrentThread()
  • by calling Thread.Sleep.

So:

  • If your long-running operation fooBar() is written in a way that it yields time
  • AND if you call foobar() from within Thread.Run()
  • Then other event handlers will continue to run.

In your specific case:

You should be able to get it working.

Exceptions to the rules above

  • Modal dialogs, which have an unusual behavior: Calling Window.ShowModal (or ShowModalWithin) will pause that eventHandler until Window.Close is called. However, while paused, other eventHandlers are allowed to run
  • App.DoEvents() which is evil and should really never be used.
  • Some Xojo methods yield internally, but only on one platform, and the documentation is sparse, so this can be a potential “gotcha”

Thank you @Michael Diehr for the clear explanation.
This knowledge makes the software developer.