>>>
>>>Wasn't my code :-}
>>>TBH I didn't weigh up the pros and cons but it looked as if either could work.....
>>
>>
>>Yep, it was mine. I know there is some room here to do this a bit different and the next time out it will get revisited. However now it works perfect and for some reason only needed to be slowed down. This is the part that is a bit puzzling. Apparently in VS with the debugger attached it runs just slow enough to be fine, but outside running the exe it gets missed. It isn't the value that is changing and causing the problem. The value changes to "LoginReady" and is logged; never changes, but the while loop never breaks out.. slowing it down a half second fixes it. I don't understand why really.
>
>Still sounds a bit risky to me - and a AutoResetEvent is simple to implement. e.g: Main Thread:

private static AutoResetEvent StartupStatusChanged = new AutoResetEvent(false);
>//Then when you want to notify the thread to carry on:
>StartupStatusChanged.Set();

Then your DoWork could be something like:

            StartupStatusChanged.WaitOne();
>            switch (StartupWorkerStatus)
>            {
>                case BackgroundWorkerStatus.LoginReady:
>                    {
>                        //Elided
>                        break;
>                    }
>                case BackgroundWorkerStatus.Failed:
>                    {
>                        break;
>                    }
>                    //etc
>            }

Here is a question. If I use the AutoResetEvent object and have a autoResetEvent.WaitOne(); in my thread, it appears I cannot issue a authenticationWorker.CancelAsync(); I just tested this and it appears to still wait for the Set(); I may have to check for a cancel right after the WaitOne();

Any thoughts on that?
Thanks
Timothy