Background: As I understand it, DispatcherTimer's Start method resets the timer's interval and thus restarts the alarm time when called so when I wrote a DispatcherTimer wrapper class I explicitly checked the IsEnabled member to see if the timer was already in the process of running and, if so, then did not call the DispatcherTimer.Start() method. The expectation was that since the timer was already running it did not need to be restarted. For the better part of two years this appeared to work just fine. However, the application that consumes this class recently started failing and the problem was traced to the DispatcherTimer wrapper class which had stopped reliably invoking the timer's alarm event. The problem was the DispatcherTimer.IsEnabled property. It was being read as true but the alarm code itself was not executing. This sort of failure is normally indicative that the DispatcherTimer was created on a worker thread and thus its dispatcher was not the foreground UI dispatcher. In this case the DispatcherTimer object itself is a property of the wrapper class and utilizes a lazy constructor so that the object delays creation until it is actually required. This lazy constructor is smart enough to pass the FG dispatcher to the timer object even if the lazy constructor is called from a worker thread.
Question: So, if the lazy constructor is thread safe in that it explicitly passes the Application.Current.Dispatcher object to the DispatcherTimer object, what would make the IsEnabled property return a true, indicating that the timer was running, but for the alarm event to never be invoked?
Richard Lewis Haggard