What could cause a Dispatcher Thread to terminate abnormally?
-
We have several embedded resources file in XML format that can be loaded at runtime. The UI is a WPF application. When these files area loaded, it constructs objects via the XmlSerializer, and those resulting objects are used to make little boxes float around a 3D window for a simulation. At some point when adding, the application appears to hang. Alright... That's happened to me a-plenty, but it throws absolutely no exception and I don't get the "Not Responding" notification. Another interesting observation is that after the hang, when the mouse is put over the app window, the control boxes flash like a rapid hover-over. When I break into the debugger (btw I have the IDE to break on all thrown exceptions) I can see where the app stops, but no data is available because the IDE reports that the executing thread is in a sleep or join state. I guess the question is how can I detect when the Dispatcher Thread takes a dirt nap? Is there a way to appoint a new thread to watch it and restart? Scott
"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand
-
We have several embedded resources file in XML format that can be loaded at runtime. The UI is a WPF application. When these files area loaded, it constructs objects via the XmlSerializer, and those resulting objects are used to make little boxes float around a 3D window for a simulation. At some point when adding, the application appears to hang. Alright... That's happened to me a-plenty, but it throws absolutely no exception and I don't get the "Not Responding" notification. Another interesting observation is that after the hang, when the mouse is put over the app window, the control boxes flash like a rapid hover-over. When I break into the debugger (btw I have the IDE to break on all thrown exceptions) I can see where the app stops, but no data is available because the IDE reports that the executing thread is in a sleep or join state. I guess the question is how can I detect when the Dispatcher Thread takes a dirt nap? Is there a way to appoint a new thread to watch it and restart? Scott
"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand
After dealing with this for two days, we found the issue. The coordinates for the floating boxes are calculated with respect to time in a wrapped timer. We changed the internal timer of that class to be a
DispatchTimerand now everything seems fine... Thanks to those that took the time to read this."Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand
-
We have several embedded resources file in XML format that can be loaded at runtime. The UI is a WPF application. When these files area loaded, it constructs objects via the XmlSerializer, and those resulting objects are used to make little boxes float around a 3D window for a simulation. At some point when adding, the application appears to hang. Alright... That's happened to me a-plenty, but it throws absolutely no exception and I don't get the "Not Responding" notification. Another interesting observation is that after the hang, when the mouse is put over the app window, the control boxes flash like a rapid hover-over. When I break into the debugger (btw I have the IDE to break on all thrown exceptions) I can see where the app stops, but no data is available because the IDE reports that the executing thread is in a sleep or join state. I guess the question is how can I detect when the Dispatcher Thread takes a dirt nap? Is there a way to appoint a new thread to watch it and restart? Scott
"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand
Just out of curiosity. how does WPF deal with gui elements and threads? is it the same as winforms idea? "only the main thread should interact with gui elements, other threads have to marshal calls to the main thread" or can threads create / interact with wpf elements freely?
Blog: http://www.rogeralsing.com Projects: http://www.puzzleframework.com
-
Just out of curiosity. how does WPF deal with gui elements and threads? is it the same as winforms idea? "only the main thread should interact with gui elements, other threads have to marshal calls to the main thread" or can threads create / interact with wpf elements freely?
Blog: http://www.rogeralsing.com Projects: http://www.puzzleframework.com
From what I've read, WPF assigns 2 threads at the start, a Render thread and a Dispatcher thread. The Render thread does the background work, while the Dispatcher thread does the work of maintain the GUI. Any explanation I give you won't be as good as this on MSDN[^] Scott
"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand