b762: Database Search Stop/Go button

Archive mAirList 3.x (English)
1

When a Database Search is started, the Go button changes to a Stop button.

BUT when the search has obviously ended, the button never changes back to a Stop button.
You have to click the button to change it back to a Stop button.

I think this has been the case for some time.

BFN
CAD

2

You mean it doesn’t change back into a Go button? That works perfectly well here. What kind of database are you using?

3

I am using a local mAirListDB.

And yes, the button does not (ever!) change back into a Go button: on my PC, you have to click the button to change it back.

BFN
CAD

4

Hm, strange. Can anybody else confirm this issue?

5

This issue (Stop never changes back to Go after a search has run) is still happening here.

Any ideas on this?

Thanks in advance.

BFN
CAD

6

What kind of database are you using again? mAirListDB?

7

Yes: a local mAirListDB. :slight_smile:

BFN
CAD

8

It’s OK here on Build 777, it reverts back after completing the search :slight_smile:

9

Still ‘broken’ here on build 785. :frowning:

Starting a search either by clicking Go or by pressing Enter after typing the search term leaves the button caption displaying Stop after the search is complete and the results are displayed. Manually clicking the Stop button is the ONLY way I can find to make it change back to being a Go button.

BFN
CAD

10

Ah. I just took a second (third? fourth?) look, and I think I know what the problem is - although I would have expected it to occur only on a very fast PC rather than on a very slow one.

Try the new build 786, please.

11

Expect the unexpected! :smiley: But, the programmer in me just has to know: what was the problem?

And THANK YOU for fixing the problem: it works perfectly in B786! ;D

BFN
CAD

12

The search is performed in a background thread, and a separate thread is used for each database connection. Whenever one of the threads has finished its work, it sends a SEARCH_DONE message to the GUI, and then terminates itself. The GUI receives this message, checks if any of the threads is still active, and if not, changes the button caption back to “Go”.

In your particular case, it seems that the SEARCH_DONE message was processed before the thread was terminated, so the GUI was still seeing an active search thread by the time it processed the message. Some sort of race condition, actually.

My solution was to introduce a “Active” variable that indicates whether the thread is still active or not. The thread sets this variable to false before sending the SEARCH_DONE message, and the GUI queries this variable rather than the thread status, so it’s not a problem when the thread is still not fully terminated by the time the message is processed.

13

I see …

I think it’s likely to have happened because the DB performance generally is somewhat s-l-o-w on my PC #(updates of a single item can take one or more seconds!), rather than a race condition. :smiley:

I should point out that this is the SQLite DB driver’s performance I’m talking about, rather than mAirListDB.

BFN
CAD

14

At that time, all database processing is done - so it’s rather that the thread isn’t terminating “fast enough”.

And, in any case, it is a race condition: Assuming that things from two threads happen in a particular order, but not enforcing that order.

15

Oh: you meant that kind of race condition! :smiley: I had misunderstood you.

BFN
CAD