Forgot to have worker thread actually check to bail out if cancel requested. - IT's done now.

[ShadowKnightMK4]

Forgot to actually code the worker thread checking for request cancel and actually bailing out.

It does so no and There's a unit test to check. UnitTest_OdinSearchBases.OdinSearch_CanWeCancilSearch_AfterStartingARun()

That triggers a full system search, waits 2 seconds, checks if a thread was cancelled yet. If not, it Triggers the request by Demo.KillSearch(). We also wait no more than 4 seconds before going any anyway to the assert.fail() status if it didn't bail ok.

Note two ways should prove the test ok.

1, found is true in the test.

2, the threads spawned based on ready drives in the hardware (know how many root drives) either send a stopped message (DEBUGVERBOSEMODE and debug buuild) along with the actual stopped message). I.e. if you got 5 drives such as drive A-E, you should have at most 5 cancel notifiy messages in the output of the test OR a combination of that + notification that the thread isn't getting canceld due to stopping already.

Worker thread is now checking at start, and just before each compare.

This should in theory help the random appearing calls into a communication class after starting a new search - THE OLD SEARCH IF ACTIVE was still triggering out in the wild. I didn't know that at the time.

[ShadowKnightMK4]

Glad that finally hit me.

When 1.5 is finished, I plan to roll the fix out to the rest (mainly main branch and Windows 1.0.0.0) varient