1. Beatrix Willius
  2. Valentina Database ADK
  3. Wednesday, January 02 2019, 02:27 PM
  4.  Subscribe via email
Since updating my app to 64bit it can handle larger amounts of data. Unfortunately, this means that "not responding" now also shows up when adding data.

Try the example "Field_FromToFile" and use it with a larger file - I have done this with a nice 300 MB file. That adding the data to a database takes 2 seconds or so isn't bad. But I can see the the app as "not responding".

Whenever an operation with Valentina takes longer (diagnosis, deleting data, checking the journal file) I still see the "not responding" - always.

I seem to remember that Ruslan said this should be improved. But I can't see this anywhere.

Wasn't this supposed to be improved for diagnosis? This never worked for me. Didn't I do an example??? Need to dig. However, all Valentina operations need to leave the application responsive.

All the best for 2019

Mit freundlichen Grüßen/Regards

Beatrix Willius

http://www.mothsoftware.com
Mail Archiver X: The email archiving solution for professionals
Comment
There are no comments made yet.
Beatrix Willius Accepted Answer
Xojo 2018r3, High Sierra, Valentina 8.6.
Comment
There are no comments made yet.
Ivan Smahin Accepted Answer
What about Database_Diagnose example? It should be no "not responding" if run it in the dedicated thread.
Comment
There are no comments made yet.
Beatrix Willius Accepted Answer
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.
Comment
There are no comments made yet.
Ivan Smahin Accepted Answer
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.
Comment
There are no comments made yet.
Beatrix Willius Accepted Answer
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
Comment
There are no comments made yet.
Ivan Smahin Accepted Answer
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.
Comment
There are no comments made yet.
Beatrix Willius Accepted Answer
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)?
Comment
There are no comments made yet.
Ivan Smahin Accepted Answer
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)
Comment
There are no comments made yet.
Beatrix Willius Accepted Answer
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.
Comment
There are no comments made yet.
Ivan Smahin Accepted Answer
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.
Comment
There are no comments made yet.
Beatrix Willius Accepted Answer
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
Comment
There are no comments made yet.
Ivan Smahin Accepted Answer
At least MySQL plugin do the same thing as we do. Xojo docs recommends Threads for long operations as well...
Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.

Categories

Announcements & News
  1. 0 subcategories
Valentina Studio
  1. 2 subcategories
Valentina Server
  1. 4 subcategories
Valentina Database ADK
  1. 0 subcategories
Valentina Reports ADK
  1. 0 subcategories
Other Discussions
  1. 0 subcategories
BETA Testing
  1. 0 subcategories
Education & Research
  1. 0 subcategories
Omegabundle
  1. 0 subcategories