Xojo 2018r3, High Sierra, Valentina 8.6.

What about Database_Diagnose example? It should be no "not responding" if run it in the dedicated thread.

The Database_Diagnose example works fine. In my app I still see the pizza of death.

In summer I spent some hours making an example out of my app. And then I forgot to send the example. I'll have a look at the example again in the next days and will send it to you guys.

Well, I was playing a bit with Diagnose example and found "beach ball" and "app not responding" sometime, though db.Diagnose is called in dedicated "Xojo thread". Googling a lot I found literally single idea (coming from Xojo doc) - "use our threads for hard operations" and a single discussion how to avoid "beach ball" even with Thread usage.

So, idea is to call App.YieldToNextThread() and App.DoEvents() inside some loop when we are waiting for the Thread finish. Well, it works - no "not responding" anymore, but docs say it is incorrect - "Using DoEvents in a GUI application will likely cause instability."

Ok, let think of it - why App.DoEvents() solves an issue. Obviously because there is some "app event loop" which this call makes work normally and app looks alive for the system. I guess that when we are inside of some control's handler that "event loop" is get stuck, so we see "beach ball" in "lengthly" handlers.

Ok, let's try to run our Thread with db.diagnose and leave the button's handler immediately - no waiting for the thread (I should come to this idea early - see - there is no "joined threads" in Xojo and there is for a good reason) . Instead, we add the Timer which is for checking the global boolean "IsThreadComplete" property periodically.
It seems to work fine now.

My code is a bit different. There is a thread which does the diagnosis and sends a notification to the caller:

  if theDatabase.Diagnose(VerboseLevel, theDiagnoseFile) then

  ...

    NotificationManager.Post "DiagnoseFinished", "Success"

The caller has 2 methods. The diagnosis itself:

dim theDiagnoser as new DiagnoseThread(theDatabase, Silent)

theDiagnoser.Run



while not DiagnoseFinished or theDiagnoser.State = Thread.Running

  app.SleepCurrentThread 100

wend

And the notification code:

if Message = "DiagnoseFinished" then

  DiagnoseFinished = true

  DiagnoseResult = UserData.StringValue

My computer is too fast so I need to make a larger database.

Mit freundlichen Grüßen/Regards

Beatrix Willius

http://www.mothsoftware.com
Mail Archiver X: The email archiving solution for professionals

I guess there is an issue:

while not DiagnoseFinished or theDiagnoser.State = Thread.Running
app.SleepCurrentThread 100
wend

Again - if you are waiting for the thread in some control's handler then you will see "app not responding" and using threads in this way makes no sense. You should check thread results in Timer.Action.

Yeah, this works fine now. I just need to untangle my spaghetti code of notifications after adding data so that the diagnosis doesn't cause an instant crash.

What about the other activities (check of journal file, adding data - both with SQL and without, deleting data)?

We can't do the same for every method, because it runs longer in "threaded" rather than "plain" approach. So we do it for potentially hard methods only.

Currently there is a list of such methods:

- db.Open
- db.Reindex
- db.Diagnose
- vSQLite.SqlExecute
- blob.FromFile (new, available since v.9.0)
- blob.ToFile (new, available since v.9.0)

Yes, I know that threaded operations take longer. However: pretty please let your users - us developers - select what they want to use. My users aren't very computer savvy. But they know it's not good when the app shows "not responding".

Also encrypting and decrypting is missing on your list.

Oh, and I want to have this available automatically. Not by decoupling everything like I will have to do for diagnosis.

Let me summarise.

[*] You should run Xojo thread from some Xojo control handler, but you must not waiting there for thread finish! If you do so, it is practically the same as a plain execution approach, because "app event loop" is get stuck until the end of the current handler call. So, you should leave the handler as soon as possible.

[*] To react on the Xojo thread finish you should use the Timer object.

[*] There are some improvements in v.9.0, so virtually every Valentina function should not cause "not responding" issue now.
There are modified V4RB examples - API_way/Database_Diagnose and API_way/Field_FromToFile to demonstrate correct implementation for long-running Valentina calls.

[*]

Oh, and I want to have this available automatically. Not by decoupling everything like I will have to do for diagnosis.

Unfortunately this is just impossible, because of Xojo. You should redesign your code to use Xojo's threads/timers for potentially long operations to avoid "app not responding" state. There is the only option currently.

Thanks for the information regarding version 9. Looking forward to the new version.

Regarding the thread/timer "my code is becoming more spaghetti with every version" situation: how do other plugins do this then? Other databases? I recently had a plugin author make me a version of a Xojo function that showed "not responding". The new function is 30% faster and yields nicely.

Regards

Beatrix Willius

At least MySQL plugin do the same thing as we do. Xojo docs recommends Threads for long operations as well...