The indeterminate progress bar doesn't appear

Targets Windows
22

Hi Mike,

I took a look at your example and need to study it because it seems a bit complicated for me. I’m puzzled by the fact that to do what I’m asking requires more complicated steps than expected.

At this point I was wondering: if I wanted to increment a progress bar with real values ​​during a “Select…” command, how can I do it since the command is synchronous?
That is, how can I display the progress during the execution of the select?

23

query a database is usually fast.

but updating the listbox could be slow if u fill it with many thausend of rows and many fields.

you could add more query filters to reduce the result rows

or maybe use

to make a sql query faster use only the fields you like to display not just *

use indices in your database table design.

24

To keep things simple, you could

  1. Enable the ProgressBar and start a Thread in which you querrie the Database and move through the Records.
  2. Before each MoveToNext (Record) you call the UserInterfaceupdate Event.
  3. You hand over the data of the Record to this event, update the ListBox and the ProgressBar.Value.

Idealy the Thread would be of Type preemptive. :slight_smile:

I took one of the Xojo examples and reworked it accordingly. Quick & Dirty, as you know me. But the principle should be clear. (16.5 KB)

25

It really depends on what your database situation is - for example if you are using SQLite where the database is on the same disk as your app, the SELECT command will probably run in a few milliseconds - so there’s literally no need to (or enough time to) deal with a progressBar.

If your database is remote and much slower, then perhaps you would want to break up your SELECT statement using LIMIT and OFFSET to return batches of results, like this:

SELECT column1, column2, ... FROM table_name LIMIT 100 OFFSET 0;

[update the UI]

SELECT column1, column2, ... FROM table_name LIMIT 100 OFFSET 100;

[update the UI]

SELECT column1, column2, ... FROM table_name LIMIT 100 OFFSET 200;

... etc...

It’s probable that this batch approach will be slower overall than doing a single SELECT statement.

However, an actively updating User Interface can also “feel” better from the user’s perspective, even if it’s slower overall - it’s a tradeoff.

What works best for your app will depend on the details.

1 Like
26

Ok Mike,

thanks for your suggestion