We observed that some threads can reach deadlock-ish state after they have Invoked into a control's UI thread. When it happens they are all in a waiting for join or in sleep state for very long time, although there should not be any deadlock situations.
It seems this has something to do with multiple parent controls and with which control we invoked on. This should not make a difference, because we have got one UI thread (for MainWindow) they should wait for, but we have seen it does.
The solution that fixed this issue was to invoke on the MainWindow instead of various controls (see a4fe507adf ).
This changeset is changing all our Invokes to invoke into MainWindow
instead of a control itself. (MainWindow's UI thread is the only UI thread
all Control is using in XenCenter)
This changeset should be in place until we have found the root cause or the exact reason for the above.
removed uninitialised streams which we were taking care to close. Solution-wide
style: use string.IsNullOrEmpty method instead of checking separately for null
and zero length.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
is expanded. Removed the title "New Search" from the panel and added a "New Search"
button which blanks the search. Renamed the "Reset" button to "Default Search" as
it wasn't obvious what it was resetting to.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
pass in parameters when the event is fired. Moved QueryElement.Dispose method
from the Designer.cs to the main file (it needs visibility since it contains more
code than the autogenerated method).
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
a Save button in the Searcher panel. Moved collapse Searcher panel functionality
from the SearchOptions dropdown menu to a Close button in the panel. Use new
Expanded property to query the state of the Searcher panel (instead of Visible).
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
